From: Adam Bien <abien_at_adam-bien.com>
Date: Mon, 22 Oct 2007 21:52:11 +0200

Hello,

we were able to narrow the problem to the class AbstractSession from the
package "oracle.toplink.essentials.internal.sessions".
Trying to add a new bidirectional M:N relation with an intermediary
entity (so actually it is N:1 <--> 1:m), Toplink sents everything, but
not the final commit to the DB-transaction (we monitored the behavior
with P6spy, as well as with DB tools).

For some reasons the two blocks of the if statements are no more
executed (also not in a new EntityTransaction)

 public void commitTransaction() throws DatabaseException,
ConcurrencyException {
        // Release mutex and call subclass specific commit.

     ####IF BLOCK ISNT EXECUTED####
        if (!getTransactionMutex().isNested()) {
            getEventManager().preCommitTransaction();
            basicCommitTransaction();
            getEventManager().postCommitTransaction();
        }

        // This MUST not be in a try catch or finally as if the commit
failed the transaction is still open.
        getTransactionMutex().release();

        // If there is no db transaction in progress
        // if there is an active external transaction
        // which was started internally - it should be committed
internally, too.

       ###//ALSO NOT THIS ONE...####
        if (!isInTransaction()) {
            commitExternalTransaction();
        }
    }

Any thoughts, whether it is possible to make recover TopLink from this
inconsistent state? What could cause such a strange behavior?
It isn't a DB/locking problem - we are still able to commit the
connection...

thank you in advance,

adam

-- 
 Consultant, Author, Java Champion
 
 Homepage: www.adam-bien.com
 Weblog: blog.adam-bien.com
 eMail:  abien_at_adam-bien.com
 Mobile: 0049(0)170 280 3144
 Books: Enterprise Architekturen (ISBN: 393504299X),
        Java EE 5 Architekturen  (ISBN: 3939084247),
        J2EE Patterns, J2EE Hotspots, Enterprise Frameworks and Struts