Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 332581

Summary: SessionBroker session event issues to consider and resolve when implementing JPA Session Broker
Product: z_Archived Reporter: David Minsky <david.minsky>
Component: EclipselinkAssignee: Project Inbox <eclipselink.foundation-inbox>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P2 CC: andrei.ilitchev, tom.ware
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Testcase demonstrating outputParametersDetected issue
none
Suggested patch.
none
Additional patch: EntityManagerSetupImpl correction plus test none

Description David Minsky CLA 2010-12-14 17:19:17 EST 
SessionEvent inconsistency with SessionBroker
Issues to consider and resolve when implementing JPA Session Broker

When executing a query against a SessionBroker, if a SessionEventHandler is defined on a child session registered with the SessionBroker, query events (preExecuteQuery, postExecuteQuery, etc.) are not fired against the child session, even though an event handler is correctly defined. The current behavior is to execute relevant events against the SessionBroker's eventManager.

Another example of this inconsistency is the 'outputParametersDetected' event. When a SessionEventListener is added to a SessionBroker, and a stored procedure call with output parameters is executed against the SessionBroker, that listener's outputParametersDetected event is not executed, however the event is executed against the SessionBroker's 'child' session.

The correct behavior and design for triggering of SessionEvents is currently vague. Ultimately a clear definition of expected behavior is required in order to resolve this ambiguity.

Some potential solutions:

1. SessionEventListeners should only be registered with a 'parent' SessionBroker, which registers its Event Listeners with every managed 'child' session, and the actual session on which the event is triggered is passed with/on the event itself

2. SessionEventListeners may be registered on any session, but EclipseLink should be aware that if a query is executed on a 'parent' SessionBroker, the event is fired on the relevant SessionEventListener registered on a relevant 'child' Session

3. (As above) but an event is fired on the 'parent' SessionBroker and 'child' Session (potentially requiring some sort of 'event consumed' flag). Order of firing the events between parent and child would need to be determined
Comment 1 David Minsky CLA 2010-12-14 17:21:45 EST 
Created attachment 185182 [details]
Testcase demonstrating outputParametersDetected issue
Comment 2 Andrei Ilitchev CLA 2011-05-11 10:23:04 EDT 
Created attachment 195358 [details]
Suggested patch.

The patch fixes exception and session events handling according to the following rules.

Exception handling:
1) if session has a parent then when the session is created exception handler is copied from the parent;
2) if session has a broker (member of SessionBroker) then broker's handler is used if session's handle either does not exist or has failed (has thrown exception).

Session Events handling:
1) when session is created if it has a parent then session events handler is cloned from the parent;
2) when DatabaseSession/ServerSession is registered with SessionBroker all the listeners from the SessionBroker are added to the DatabaseSession/ServerSession;
3) when a listener is added/removed to/from SessionBroker it is also added/removed to/from all member sessions;
4) adding/removing listener to/from EventSessionManager could be done concurrently - it's thread safe.

What do these rules mean for SessionBroker users?
1) If exception or event originates in a UnitOfWork then it will be handled by its parent SessionBroker, NOT by member sessions;
2.1) If exception originates on a member session, then it's handled by this member session only, if there is no handler or handler fails then the exception is handled by the broker.
2.2) If event originates on a member session then it is passed to the listeners assigned to this member session AND to the listeners copied from broker. Note that the session passed with the event is always the member session.
2.3) The most straightforward strategy is to register all SessionEventListeners with SessionBroker. That guarantees that the event will be always called and it will be easy to handle because the member session or unit of work on which the event originated is passed with the event.
3) Thread safety of EventSessionManager is essential when adding a new listener to a session while it is concurrently used (adding a listener to connected ServerSession or ServerSession SessionBroker).

Tests are coming soon.
Comment 3 Andrei Ilitchev CLA 2011-05-11 18:46:47 EDT 
Checked the patch into trunk.
Reviewed by James and David Minsky.
The test are coming soon.
Comment 4 Andrei Ilitchev CLA 2011-05-16 11:40:39 EDT 
Created attachment 195745 [details]
Additional patch: EntityManagerSetupImpl correction plus test

Corrected EntityManagerSetupImpl to use addListener method (instead of getListeners().add) - addListener also adds the same listener to members of the composite.
Also changed ordering of processing of session event listeners in updateSessions method so that listeners processed first for members, then for the composite.

If session listener is added before ServerSession (that's the case when listeners specified in persistence unit properties) is created then ServerSession's listeners will appear on the list before SessionBroker's ones.
However after ServerSession has been created listeners are added in chronological order.
Comment 5 Andrei Ilitchev CLA 2011-05-16 11:41:36 EDT 
Also added testSessionEventListeners to composite.advanced.EntityManagerJUnitTestSuite.
Comment 6 Andrei Ilitchev CLA 2011-05-16 11:44:55 EDT 
Checked the patch into trunk.
Comment 7 Eclipse Webmaster CLA 2022-06-09 10:07:38 EDT 
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink