Desparately need help with JPA (Toplink) cache problems

[glassfish]

I've been battleing this problem for a long time.  The problem that I am seeing is that the Toplink cache is becoming inconsistent.  My code has a parent->child entity bidirectional relationship (and yes I wire up both sides correctly) and when I remove a child entity, in a later transaction, the system the parent entity with the child entity that I removed still attached in the cache.  I've attached a snippet of the log.

Thread#19 is in one client transaction.  It is going to remove an entity called Chassis9145ConfigSet with ID=428.  At the log entry with time "2008-07-24T12:04:30.125-0400", Toplink reports a that the remove operation has been performed.  At "2008-07-24T12:04:30.125-0400" the SQL to delete the entity is echoed out by toplink.  At time "2008-07-24T12:04:30.375-0400", Toplink echos that it has "Unregistered the object....[id=428]".  At time "2008-07-24T12:04:30.656-0400", Toplink echos out that the transaction "status=COMMITTED" so this transaction is complete.

At time "2008-07-24T12:04:30.656-0400", Thread#19 is active again, and Toplink echos a "Execute query ReadObjectQuery" and then at time "2008-07-24T12:04:32.359-0400", Toplink echos "Register the exiting object ...[id=428]".  THIS IS THE ENTITY THAT WAS EARLIER REMOVED!  

Later the code will try to remove this entity again at time "2008-07-24T12:04:32.468-0400" at which point there is a database exception.

Toplink itself spits out that it is "Unregistering" the object, but later it registers the existing object?

The problem seems to occur quite readily when I have another client that is accessing the same parent entity at the same time that this transaction is going on. It is as if the parent object that Toplink finds in the cache is not the same one that had the child entity removed but rather a different object.  

One interesting thing that I just thought of was that I am using the @Version and optimistic locking but when I remove the child entity, I never see the parent entity rewritten to the database with its "version" updated.  Because the relationship is owned by the parent and uses a "mappedBy" annotation parameter, I'm not sure if the version column should be updated or not.  

But for some reason, the cache either has a different object, with the child entity still attached.

Any help trying to debug this problem will be greatly appreciated!

Brett
[Message sent by forum member 'bbergquist' (bbergquist)]

http://forums.java.net/jive/thread.jspa?messageID=289133

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[glassfish]

Hello,

From the log, it looks like the application is reading in an object that references the Chassis9145ConfigSet id=428, and then attempting remove it from the database.  Later on, another read is performed and the same Chassis9145ConfigSet id=428 is found referenced and it is again attempted to be removed from the database, causing the exception.

My guess is that when the application calls em.remove on the Chassis9145ConfigSet entity, it is not clearing all references to it.  Later on, when an entity is read in from the cache that is left referencing it, this causes it to become managed as if it still exists.  If this is the case, this is covered by the specification - the application is required to clear all references to objects before they are removed.  I would start with checking the Chassis9145 object that is read in, as I suspect it has a 1:M to Chassis9145ConfigSet.

Depending on the order objects are checked for changes, leaving references to deleted objects might get you this issue, or might cause them to be 'undeleted' in the same transaction - resulting in the delete statement not being issued.

Best regards,
Chris
[Message sent by forum member 'chris_delahunt' (chris_delahunt)]

http://forums.java.net/jive/thread.jspa?messageID=289156

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[glassfish]

The references are being cleared correctly.  I dump out the references to make sure (see the lines with XXX in them).  Also here is the code that is doing the work:

    /** Add a new ConfigurationSet to this Hardwre.  This determines if
     * there are too many configurations and if so, removes the oldest configurations.
     * @param cs The ConfigurationSet to add
     */
    public void addConfigurationSet(ConfigurationSet cs) {
        // Wire up this configuration set
        cs.setConfigurableHardware(this);
        this.configurations.add(cs);
        // Check to see if we need to remove a configuration set
        while (this.configurations.size() > MAX_OLD_CONFIGURATIONS) {
            ConfigurationSet ocs = getOldestConfigurationSet();
            this.configurations.remove(ocs);
            EntityManagerFactoryFacade.getEntityManager().remove(ocs);
        }
    }

There is actually a couple of base classes involved: ConfigurableHardware (which Chassis9145 ultimately is derived from) and ConfigurationSet (which ConfigurationSet9145 is ultimately derived from).  When a ConfigurationSet is added to ConfigurableHardware, it comes into this method.  The method adds the ConfigurationSet to the collection that ConfigurableHardware maintains and sets the ConfigurableHardware of the ConfigurationSet to "this" ConfigurableHardware.

When the maximum ConfigurationSets are reached, the oldest ConfigurationSet is located and then removed.  The ConfigurationSet is removed from the ConfigurableHardware collection and then the EntityManager.remove is called on the ConfigurationSet.  

The EntityManagerFactoryFacade is just a class that I wrote that allows me to return a wrapped EntityManager instance.

So I believe I am removing the relationships correctly.  If there is something wrong, it is right here as there is no other code that can alter the collection or set the ConfigurableHardware for the ConfigurationSet.

An interesting note.  Just on a whim, I removed the @Version attribute on the MappedSuperclass that all of these derive from so basically I removed the OptimisticLocking mechanism.   I no longer observe the same behavior.  Could something be wrong with the OptimisticLocking?

I appreciate the time taken to look at this and ggive me some pointers.

Brett
[Message sent by forum member 'bbergquist' (bbergquist)]

http://forums.java.net/jive/thread.jspa?messageID=289164

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[glassfish]

Hello,

From the log, the xxx lines seem to show that after the commit none of the changes are in the collection.  The removed 428 is still there, and the inserted 433 is missing.

Can you show the mapping from the ConfigurableHardware  to ConfigurationSet?  Is ordering specified by any chance? (if so, you might be seeing something similar to the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=237545 )  

You are probably right in that it has to do with versioning.  If you change a basic field in the ConfigurableHardware in the same transaction that you initially add or remove from the collection, do you still see the problem?

Best Regards,
Chris
[Message sent by forum member 'chris_delahunt' (chris_delahunt)]

http://forums.java.net/jive/thread.jspa?messageID=289177

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[glassfish]

No @OrderBy.  I have already been bitten by that bug :(  I work around the ordering by returning an ordered list via the accessor methods now.

Note that I had a different problem with both Toplink and Eclipselink.  I boiled it down into about a 20 line program and wrote a bug up agains Eclipselink because I figured that was where the future work was going to be done.

The bug is:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=241388

I've attached ConfigurableHardware.java and ConfigurationSet.java.  There are other entity relationships being maintained by these entities but I did not include their sources as I don't think they matter.
[Message sent by forum member 'bbergquist' (bbergquist)]

http://forums.java.net/jive/thread.jspa?messageID=289182

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...