jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zschorn, Andreas" <AZsch...@zeb.de>
Subject Transactionhandling broken since JCR-2523
Date Mon, 21 Feb 2011 02:21:37 GMT
Hi,

we upgraded from jackrabbit 1.6.0 to 2.2.4 and we have massive problems with the transaction
handling afterwards.
For us the complete transaction handling is broken.

I assume it is a problem of our side so perhaps somebody can help.

Situation is:
Jackrabbit as connected via an jca adapter on jboss 4.2.3 via spring modules.

Our error is that that the internal sessions are not connected to the transaction anymore
after the connection was going back to the pool.

After some debugging, I  found problem comes through the following changes in the JCAManagedConnection
with ticket JCR-2523 at the JCAManagedConnection.
In the constructor the current session is connected to the xaResource via
<code>
        if (this.mcf.getBindSessionToTransaction().booleanValue()) {
            this.xaResource =  new TransactionBoundXAResource(this, (XAResource) session);
</code>

And when the connection is going back to the pool, a new session is created in the cleanup
code via openSession and the xaResource is not anymore connected to the current session. The
old code was just to call session.refresh(false) during cleanup.

The problem is that only the xaResource is updated from the current transaction with the appropriate
transaction context. Not the session object anymore. The result is, that session.save immediately
saves to the database, because it does not know it is in a transaction context. In our case
the complete transaction safety does not work anymore. (XAItemStateManager tx is null)

I am not deep enough in the code of jackrabbit, but this is, as far as I can see it, a wrong
behavior.
I will see that I will write a testcase for this, but I have the feeling that I missed something
fundamental, that's the reason I did not write an ticket yet.

Has anyone the same problems, or know for sure that the transaction handlings works? The current
testcases are not sufficient enough, as far as I can see.
Thanks and I hope somebody can help me to understand how it is supposed to work.

Andreas Zschorn
________________________________________
zeb/information.technology gmbh & co. kg
Hammer Straße 165
48153 Münster
Phone

+4925197128-593

Fax

+4925197128-101

E-Mail

AZschorn@zeb.de<mailto:AZschorn@zeb.de>

WWW

http://www.zeb.de



Amtsgericht Münster | HRA 5127
Geschäftsführer: Martin Danne | Jürgen Hofner | Andreas Schick

Diese E-Mail und alle angefügten Dateien sind vertraulich und ausschließlich für den Adressaten
bestimmt. Sollten Sie nicht der bezeichnete Adressat sein, informieren Sie bitte umgehend
den Absender. Die Inhalte dieser E-Mail dürfen in diesem Fall nicht an Dritte weitergegeben,
für keine Zwecke genutzt und in keiner Form gespeichert oder kopiert werden. Im Fall technischer
Probleme mit dieser E-Mail wenden Sie sich bitte an den Absender.


This e-mail and any attachments are confidential and may also be privileged. If you are not
the named recipient, please notify the sender immediately and do not disclose the contents
to another person, use it for any purpose, or store or copy the information in any medium.
In the event of any technical difficulty with this e-mail, please contact the sender.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message