| Noob Problem: ClientSession.getAccessors() returns null [message #885799] |
Wed, 13 June 2012 12:06  |
Eclipse User |
|
|
|
I'm a newbie to toplink so apologize if this is not the right forum for this type of discussion.
I've been asked to bring out current eclipselink implementation based on 2.0.2 up to 2.3.2.
I'm hitting an NPE whenever I try to save an object to the database (reads appear to work fine).
Digging into the code, I see that the NPE happens in the DataSourceCallQueryMechanism method updateObject() at line 773:
AbstractSession executionSession = this.query.getExecutionSession();
for (Accessor accessor : executionSession.getAccessors()) { // <-- NPEs here
accessor.flushSelectCalls(executionSession);
}
The 'executionSession' in my case is a ClientSession.
Looking at the ClientSession implementation of that method, I noticed that it can indeed return null:
(ClientSession, line # 279)
@Override
public Collection<Accessor> getAccessors() {
if (isInTransaction()) {
if (this.writeConnections == null) {
return null;
}
return this.writeConnections.values();
} else {
return this.accessors;
}
}
So it looks to me that the consumer code in DataSourceQueryMechanism is in error since it's not coded to handle a null return - is this bug?
Alternatively, is this a problem with my existing application (that works swimmingly with 2.0.2) - and that the situation where a null can be returned from any of the getAccessors() implementations should never occur?
My approach would be to either check for null in the consumer, or return an empty collection where null is currently returned - but before wading into to hack code, I'm curious if anyone else has seen problems similar to this with the 'new' partioning implementation.
Note: I'm not using partitioning - this is a pretty standard toplink-style app (no JPA annotations)
|
|
|
|
|
|
| Re: Noob Problem: ClientSession.getAccessors() returns null [message #902212 is a reply to message #901972] |
Thu, 16 August 2012 07:53  |
| Eclipse User |
|
|
|
Hi,
we found the culprit in our code. 
The application employs several DAO objects that use the EclipseLink session internally (acquired in the constructor).
For complex scenarios the DAOs can cooperate and share a session.
The DAOs offer a close() method that releases the EL session and UnitOfWork (if any exists) this close method is usually called after the work is done. However, to prevent resource leakage, the DAOs have a finally method implementation that calls close.
In some places, the cooperation was not fully established (requires two method calls), so that two DAOs shared a session and both thought they were responsible for the session's release. When one DAO was going out of scope and the Finalizer thread called the finalize method, while the normal request thread was committing the same session, the NPE on DatasourceCallQueryMechanism l.773 resulted.
A retest with the earlier release EclipseLink 2.1.2 did not reproduce the same bug as easily but lead to the following exception:
Exception [EclipseLink-4022] (Eclipse Persistence Services - 2.1.2.v20101206-r8635): org.eclipse.persistence.exceptions.DatabaseException
Exception Description: Accessor or its connection has been set to null. This can occur if the ClientSession or UnitOfWork was released in a seperate thread, for instance if a Timeout occurred.
at org.eclipse.persistence.exceptions.DatabaseException.databaseAccessorConnectionIsNull(DatabaseException.java:133)
at org.eclipse.persistence.sessions.server.ClientSession.getAccessor(ClientSession.java:231)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.insertObject(DatasourceCallQueryMechanism.java:365)
Greetings,
Stephan
|
|
|
Powered by
FUDForum. Page generated in 0.03735 seconds
Home