Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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 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.

Also added testSessionEventListeners to


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:
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
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

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
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
member session only, if there is no handler or handler fails then the
is handled by the broker.
2.2) If event originates on a member session then it is passed to the
assigned to this member session AND to the listeners copied from broker.
that the session passed with the event is always the member session.
2.3) The most straightforward strategy is to register all
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
to a session while it is concurrently used (adding a listener to
ServerSession or ServerSession SessionBroker).

Tests are coming soon.
eclipselink-dev mailing list
eclipselink-dev mailing list

Back to the top