On 07/04/2012 04:13 PM, Stefan Guggisberg wrote:
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?
Your initial reply I'd say... plus the impression that a lot of people
have wondered about it and have received much less helpful replies (see
below).
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
That's the pointer I needed. Thanks!
[1]
http://jackrabbit.apache.org/api/2.4/org/apache/jackrabbit/api/XASession.html
And this one is also great.
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
