Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Noob Problem: ClientSession.getAccessors() returns null(Upgrade to 2.3.2 causes exising code to NPE in updateObject())
Noob Problem: ClientSession.getAccessors() returns null [message #885799] Wed, 13 June 2012 16:06 Go to next message
Thom Park is currently offline Thom ParkFriend
Messages: 12
Registered: June 2012
Junior Member
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 #889735 is a reply to message #885799] Tue, 19 June 2012 14:22 Go to previous messageGo to next message
James Sutherland is currently offline James SutherlandFriend
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

Please log a bug. Although it is very odd for there to be no accessor at this point, it would mean that no update occurred.

James : Wiki : Book : Blog : Twitter
Re: Noob Problem: ClientSession.getAccessors() returns null [message #896299 is a reply to message #889735] Tue, 17 July 2012 22:59 Go to previous messageGo to next message
Thom Park is currently offline Thom ParkFriend
Messages: 12
Registered: June 2012
Junior Member
Forgive the late reply.

I can certainly log a bug but I'm loathe to do so without a simple reproduction. This issue only happens in our product stack - and it is a somewhat convoluted application that uses 'old-style' top-link Object mapping (via the eclipse link workbench) rather than JPA-era annotations.

Other than wading through the code (which I'm in the process of doing) is there anything written down regarding the lifecycle management of the various Session types in eclipse link?

As far as I can tell this failure happens when we first try to write a change to the database - retrievals have already successfully occurred so I'm wondering why this client session would appear to be a 'first-time-used' session (since the 'writeConnections' collection is empty.

Is there any diagnostic modes I can turn on that would allow me to track the life-cycle of the session, connections and such? (I'll go look a the code again) but just thought i'd ask.

tyanks!

Thom


Re: Noob Problem: ClientSession.getAccessors() returns null [message #901972 is a reply to message #885799] Wed, 15 August 2012 11:19 Go to previous messageGo to next message
Stephan Gross is currently offline Stephan GrossFriend
Messages: 2
Registered: August 2012
Junior Member
Hello Thom,

we currently experience the same problem as you:
A NPE on DataSourceCallQueryMechanism l.773 every other day.
We have an application built with the EclipseLink mechanisms (not JPA) and most of the commit()s work.
Only sometimes the l.773 throws an exception.

I have a JMeterTest that performs several steps in a workflow of our web application. Sometimes the fourth, seventh or even the first repetition triggers this bug.

Now I had an amazing situation in my Eclipse debugger:
A breakpoint on ClientSession l.279 was hit but the variables inspector showed that this.writeConnections is initialized to a HashMap.
I still do not know how this has occurred or why the if statement in l.278 evaluated to true. We are after the DatasourceCallQueryMechanism executeCall() (l.749) and the returnedRowCount is 1, so the writeConnections ought to be set.

A multi-threading issue could explain such strange behaviour, but EclipseLink does not employ Threads as far as I can see.

I do not have a small repeatable test case yet but am happy that some other unlucky developer has hit the same mystery.

Greetings,
Stephan
Re: Noob Problem: ClientSession.getAccessors() returns null [message #902212 is a reply to message #901972] Thu, 16 August 2012 11:53 Go to previous message
Stephan Gross is currently offline Stephan GrossFriend
Messages: 2
Registered: August 2012
Junior Member
Hi,

we found the culprit in our code. Embarrassed

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
Previous Topic:Secondary Table Cascade Delete issue
Next Topic:@OneToMany Annotation problem
Goto Forum:
  


Current Time: Fri Apr 26 03:01:42 GMT 2024

Powered by FUDForum. Page generated in 0.03314 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top