Hi Marcel,
On 7/9/07, Marcel May <[EMAIL PROTECTED]> 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
