Questions regarding SessionEventListener and EntityManager.flush()

[patric-5]

Hello everyone,

I've got two questions regarding the SessionEventListener concept
and flushing the entity manager (either explizit or implicit).

1. Shouldn't RepeatableWriteUnitOfWork.writeChanges() also call the  
getEventManager().preCommitUnitOfWork()?
so that a SessionEventListener has a change to intercept this call ?
Otherwise it is not directly possible to intercept an EntityManager flush().
This is even more difficult if the flush is implicit (e.g. before  
executing a query)

2.
Case 1:
Imagine that some managed entities got changed, and a flush() will be  
(successfully) executed.
Will the changeset of further flush() calls (or even a transaction  
commit) contain those entities again, or will they be removed in the  
changeset which is "delivered" through the SessionEvent?

Case 2:
And to how will the changeset look in the following situation:
1. a new entity will be persisted
2. flush() will be called, changeset contain the entity, marked as "new".
3. this entity will now be changed by the application
4. flush()/transaction commit will be invoked.
5. how does the changeset (in the preCommitUnitOfWork() event) look  
like? is the entity still marked as "new"?

Best regards,
Patric


_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[James Sutherland]

1 - Calling preCommitUnitOfWork in flush does not seem correct, as it is not a commit.  A pre/postFlushUnitOfWork event would be useful though, please log an enhancement request for this.  There are also the pre/postCalculateUnitOfWorkChangeSet events which might be useful.

2 - The UnitOfWorkChangeSet used to commit, will only contains the change being committed in that write, it will not contain previously flushed changes.  If an object was new before a flush, then changed, in the commit/next flush it will not be new.

The UnitOfWork merge will contain the entire change set for the whole transaction.  The RepeatableWriteUnitOfWork contains a second change set that include the cumulative changes (cumulativeUOWChangeSet), however there does not seem to be a get method for this, please log a bug to have one added, then you can access this change set if you require.

patric-5 wrote:

Hello everyone,

I've got two questions regarding the SessionEventListener concept
and flushing the entity manager (either explizit or implicit).

1. Shouldn't RepeatableWriteUnitOfWork.writeChanges() also call the  
getEventManager().preCommitUnitOfWork()?
so that a SessionEventListener has a change to intercept this call ?
Otherwise it is not directly possible to intercept an EntityManager flush().
This is even more difficult if the flush is implicit (e.g. before  
executing a query)

2.
Case 1:
Imagine that some managed entities got changed, and a flush() will be  
(successfully) executed.
Will the changeset of further flush() calls (or even a transaction  
commit) contain those entities again, or will they be removed in the  
changeset which is "delivered" through the SessionEvent?

Case 2:
And to how will the changeset look in the following situation:
1. a new entity will be persisted
2. flush() will be called, changeset contain the entity, marked as "new".
3. this entity will now be changed by the application
4. flush()/transaction commit will be invoked.
5. how does the changeset (in the preCommitUnitOfWork() event) look  
like? is the entity still marked as "new"?

Best regards,
Patric