You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Marcel May <ma...@consol.de> on 2007/07/09 10:49:08 UTC
Questions about TX in Jackrabbit, JTA and Spec compliance
I have two questions about Jackrabbit and tx handling.
1) Using Jackrabbit deployed as resource adapter (JCA) and using a
BundlePersistenceManager, I wonder if it is XA compliant:
The persistence manager BundleDbPersistenceManager invokes
setAutoCommit() and commit() on the db connection in the
store(ChangeLog) method.
This is illegal for managed connections (JTA and XA), right?
So what is the right PM/FS for JCA when I want XA? Is it possible at all?
2) I wonder if the current Jackrabbit impl. is specification conform.
I see a conflict with the JCR spec, chapter 8.1 about TXs and JCR
implementations:
"A compliant content repository may support transactions. If it does
so, it must adhere to the Java Transaction API (JTA) specification
(see http://java.sun.com/products/jta/index.html).
Whether a particular implementation supports transactions can be
determined by querying the repository descriptor table with
Repository.getDescriptor("OPTION_TRANSACTIONS_SUPPORTED")"
The return value of
session.getRepository().getDescriptor("option.transactions.supported")
is true, but no JTA is used (again, look at the persistence manager
implementations like BundlePersistenceManager, where TX operations are
performed directly on the database connection instead handled by a
transaction manager).
I'm really confused ... did I misunderstand the JCR Spec and JTA/XA?
Thanks,
Marcel
Re: Questions about TX in Jackrabbit, JTA and Spec compliance
Posted by Dominique Pfister <do...@day.com>.
Hi Marcel,
On 7/24/07, Marcel May <ma...@consol.de> wrote:
> Jackrabbit JCA basically wraps Jackrabbit Core, but still all the Core
> PersistenceManager and FileSystem implementations
> are used. These, as you mentioned as well, use and manager their own
> JDBC connections and therefore can never be JTA/XA compliant:
>
> - JTA/XA requires using a (distributed) transaction manager
> - Jackrabbit directly invokes setAutoCommit/commit/rollback without a
> transaction manager (illegal in JTA/XA terms!)
> - Jackrabbit Workspace with a DB FileSystem and DB PersistenceManager
> have two separate configured connections w/o a transaction manager.
>
> Example:
> - If Jackrabbit rolls back a TX directly on a connection, the
> distributed transaction will not know about this.
> - If the distributed TX is rolled back, Jackrabbit might already have
> invoked con.commit() ... therefore no
> rollback is possible.
When using Jackrabbit JCA, every repository operation made on behalf
of a distributed transaction is recorded in a "change log", something
not associated with the JDBC connection used normally. This change log
will not be persisted on invididual "save" calls, but only when the
respective method calls on the XAResource interface, exposed by
Jackrabbit JCA, are invoked. Therefore, I don't think the situations
you describe are actually encountered.
> Spec says a JCR impl can support TXs, and if it supports TXs it must
> support JTA. Right?
I'd say so.
> The Jackrabbit impl. can not be transactional on workspace level if
> internally a
> database PersistenceManager and a databasse FileSystem each have their
> own database connection:
> An operation spawns the persistence manager (=pm) and the filesystem
> (=fm), right?
> If one part (fm/pm) succeeds and is commited, the other part (fm/pm)
> might fail and
> therefore violate the ACID principle?
> How do the two db connections of PM and FS work together?
> This IMO can only be managed by JTA/XA.
AFAIK, the FS is mainly used for configuration purposes and therefore
plays an important role on startup. PM, on the other side, is the one
used when it comes to saving content in the repository. You're right,
that a combination of PM/FS operations is conceivable where one side
reports success and the other doesn't, but that shouldn't happen in
real life.
Again, when using Jackrabbit JCA, every operation that could
potentially end up in a JDBC call writing some data, is rather logged
to some internal storage and only executed when the distributed
transaction is committed. It is only at that point in time, that all
changes are written at one time using the PM's JDBC connection.
Cheers
Dominique
> P.S.: I'd be willing to provide a documentation patch at the end of this discussion :-)
Always happy to find some volunteers :-)
Re: Questions about TX in Jackrabbit, JTA and Spec compliance
Posted by Marcel May <ma...@consol.de>.
Hi Dominique!
Dominique Pfister wrote:
> Hi Marcel,
>
> On 7/9/07, Marcel May <ma...@consol.de> wrote:
>> I have two questions about Jackrabbit and tx handling.
>>
>> 1) Using Jackrabbit deployed as resource adapter (JCA) and using a
>> BundlePersistenceManager, I wonder if it is XA compliant:
>>
>> The persistence manager BundleDbPersistenceManager invokes
>> setAutoCommit() and commit() on the db connection in the
>> store(ChangeLog) method.
>>
>> This is illegal for managed connections (JTA and XA), right?
>> So what is the right PM/FS for JCA when I want XA? Is it possible at
>> all?
>
> The JDBC connection Jackrabbit uses is not a "shared resource",
> managed by some external component, but opened/used/closed by
> Jackrabbit itself. Therefore, I don't consider this behaviour as being
> illegal in terms of JTA/XA. Please correct me, if I'm wrong.
>
If there's no JTA/XA support, the only szenario for deploying Jackrabbit as
a JCA Resource would be for sharing it across applications in the
application server (=>ok).
I thought you would use Jackrabbit JCA to get Jackrabbit participating
in a distributed transaction (XA).
It says XA is supported by Jackrabbit if the JCA adapter is used.
Quote from the jackrabbit site http://jackrabbit.apache.org/doc/deploy.html:
" This setup also allows to take advantage of the XA facilities of the
Application Server and could use the application servers single sign-on
mechanisms that are provided as part of the J2EE framework."
So here it is wrongly mentioned that Jackrabbit JCA brings you JTA/XA
support?
Jackrabbit JCA basically wraps Jackrabbit Core, but still all the Core
PersistenceManager and FileSystem implementations
are used. These, as you mentioned as well, use and manager their own
JDBC connections and therefore can never be JTA/XA compliant:
- JTA/XA requires using a (distributed) transaction manager
- Jackrabbit directly invokes setAutoCommit/commit/rollback without a
transaction manager (illegal in JTA/XA terms!)
- Jackrabbit Workspace with a DB FileSystem and DB PersistenceManager
have two separate configured
connections w/o a transaction manager.
Example:
- If Jackrabbit rolls back a TX directly on a connection, the
distributed transaction will not know about this.
- If the distributed TX is rolled back, Jackrabbit might already have
invoked con.commit() ... therefore no
rollback is possible.
>> 2) I wonder if the current Jackrabbit impl. is specification conform.
>> I see a conflict with the JCR spec, chapter 8.1 about TXs and JCR
>> implementations:
>>
>> "A compliant content repository may support transactions. If it does
>> so, it must adhere to the Java Transaction API (JTA) specification
>> (see http://java.sun.com/products/jta/index.html).
>> Whether a particular implementation supports transactions can be
>> determined by querying the repository descriptor table with
>> Repository.getDescriptor("OPTION_TRANSACTIONS_SUPPORTED")"
>>
>> The return value of
>> session.getRepository().getDescriptor("option.transactions.supported")
>> is true, but no JTA is used (again, look at the persistence manager
>> implementations like BundlePersistenceManager, where TX operations are
>> performed directly on the database connection instead handled by a
>> transaction manager).
>>
>
> I'm not sure if I get you there: should Jackrabbit return "false"
> because of your first argument above?
>
Yes.
Spec says a JCR impl can support TXs, and if it supports TXs it must
support JTA. Right?
Can some Spec expert on the mailing list comment on this?
The Jackrabbit impl. can not be transactional on workspace level if
internally a
database PersistenceManager and a databasse FileSystem each have their
own database connection:
An operation spawns the persistence manager (=pm) and the filesystem
(=fm), right?
If one part (fm/pm) succeeds and is commited, the other part (fm/pm)
might fail and
therefore violate the ACID principle?
How do the two db connections of PM and FS work together?
This IMO can only be managed by JTA/XA.
I understand transaction as on eg Workspace level, not PM or FS level.
> Kind regards
> Dominique
Dominique, thanks alot for your comments. I really would like to clarify
on this.
My understanding of Jackrabbit internals is not that great, but the
individual
connections in FS and PM for a Workspace confuse me as how a tx for two
connections is handled correctly.
And I'd really like to use Jackrabbit JCA with XA support, for which I
have these concerns.
Cheers, and thx a million -
Marcel
P.S.: I'd be willing to provide a documentation patch at the end of this
discussion :-)
Re: Questions about TX in Jackrabbit, JTA and Spec compliance
Posted by Dominique Pfister <do...@day.com>.
Hi Marcel,
On 7/9/07, Marcel May <ma...@consol.de> wrote:
> I have two questions about Jackrabbit and tx handling.
>
> 1) Using Jackrabbit deployed as resource adapter (JCA) and using a
> BundlePersistenceManager, I wonder if it is XA compliant:
>
> The persistence manager BundleDbPersistenceManager invokes
> setAutoCommit() and commit() on the db connection in the
> store(ChangeLog) method.
>
> This is illegal for managed connections (JTA and XA), right?
> So what is the right PM/FS for JCA when I want XA? Is it possible at all?
The JDBC connection Jackrabbit uses is not a "shared resource",
managed by some external component, but opened/used/closed by
Jackrabbit itself. Therefore, I don't consider this behaviour as being
illegal in terms of JTA/XA. Please correct me, if I'm wrong.
> 2) I wonder if the current Jackrabbit impl. is specification conform.
> I see a conflict with the JCR spec, chapter 8.1 about TXs and JCR
> implementations:
>
> "A compliant content repository may support transactions. If it does
> so, it must adhere to the Java Transaction API (JTA) specification
> (see http://java.sun.com/products/jta/index.html).
> Whether a particular implementation supports transactions can be
> determined by querying the repository descriptor table with
> Repository.getDescriptor("OPTION_TRANSACTIONS_SUPPORTED")"
>
> The return value of
> session.getRepository().getDescriptor("option.transactions.supported")
> is true, but no JTA is used (again, look at the persistence manager
> implementations like BundlePersistenceManager, where TX operations are
> performed directly on the database connection instead handled by a
> transaction manager).
>
I'm not sure if I get you there: should Jackrabbit return "false"
because of your first argument above?
Kind regards
Dominique