|Re: [eclipselink-dev] Bug 332581 - SessionBroker session event issues to consider and resolve when implementing JPA Session Broker|
Checked the patch into trunk. Additional patch: EntityManagerSetupImpl correction plus test Corrected EntityManagerSetupImpl to use addListener method (instead ofgetListeners().add) - addListener also adds the same listener to members of the composite.
Also changed ordering of processing of session event listeners inupdateSessions 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 thenServerSession's listeners will appear on the list before SessionBroker's ones.
However after ServerSession has been created listeners are added in chronological order. Also added testSessionEventListeners to composite.advanced.EntityManagerJUnitTestSuite. Thanks, Andrei On 5/11/2011 6:47 PM, Andrei Ilitchev wrote:
Checked the patch into trunk. Reviewed by James and David Minsky. The test are coming soon. On 5/11/2011 10:26 AM, Andrei Ilitchev wrote:https://bugs.eclipse.org/bugs/show_bug.cgi?id=332581 The patch is ready for review. 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. _______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-dev_______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
Back to the top