On Wed, Jul 4, 2012 at 2:39 PM, Henning Blohm <[email protected]> wrote: > Stefan, > > does that in fact mean that there is no way to get atomic changes in > Jackrabbit?
no, what leads you to this conclusion? > Or is there just some Jackrabbit specific way of controlling an > underlying transaction? no, see [0] and [1]. > > Or in short: Is it true that jackrabbit commits changes at some time of its > choice and there is nothing we can do about it? hell, no! again, what leads you to this belief? [0] http://www.day.com/specs/jcr/2.0/21_Transactions.html [1] http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/XASession.html > > Thanks, > Henning > > > On 07/04/2012 01:50 PM, Stefan Guggisberg wrote: >> >> On Wed, Jul 4, 2012 at 12:33 PM, Subscriber <[email protected]> wrote: >>> >>> Hi there, >>> >>> we are using Jackrabbit 2.2.5. >>> The workspace is persisted in a MySql database using a JNDI datasource in >>> conjunction with JTA (we are using MySqlPersistenceManager). >>> >>> In the javadocs of javax.jcr.Session#save() is written - cite: >>> >>> "If the save occurs within a transaction, the changes are dispatched but >>> are not persisted until the transaction is committed." >>> >>> So we assume that changes are not persisted, if session.save() is called, >>> but the transaction is rollbacked afterwards (let's say due to an >>> exception). >>> However we discover that changes are persisted already after a >>> session.save() call. Does jackrabbit calls commit() by itself? >> >> jackrabbit expects to be in full control of the underlying database >> connection, see [0]. >> >> cheers >> stefan >> >> [0] >> http://jackrabbit.apache.org/jackrabbit-configuration.html#JackrabbitConfiguration-Persistenceconfiguration >> >>> Thanks in advance for any help and best regards >>> Udo >>> >>> >>> > >
