jarlebh wrote:
I am trying to use the BundleDbPersistenceManager in an J2EE environment with
Datasource lookup.
But it cannot work because Jackrabbit calls setAutoCommit(true) on the
Connection.
And our app server (Oracle 10g) does not allow calls to setAutoCommit.
You're right - setAutoCommit on a managed DS is illegal. You have to use
an 'unmanaged' datasource
(where the app server does not control the TXs).
You should try the Jackrabbit JCA which gives you support for
distributed TXs - that's
probably what you want in an Enterprise environment.
I look at Jackrabbit JCA as a transactional 'black box': whatever is the
final storage (DB, FS, ...),
the TXs are handled at JCR API-level. The DB connection underneath is
hidden. For XA, Jackrabbit ensures
that in the two Commit phases work according to the spec. For this it
needs full control of the db connection underneath.
Remember, the transactional 'contract' is with JK and not with the db
connection underneath (as
this would 'bypass' JK).
So, using a managed db connection for JK is a bad idea, as JK must honor
the TX contract,
whatever the storage underneath does.
BTW, please be aware of the costs of distributed TXs - this feature is
not cheap :-(
Anyone correct me please ...
From the source code I can see that it calls setAutoCommit(false) before
storing, so why does it call setAutoCommit(true) ???
It will probably fail on the commit call also, since the commit should be
handled by the TransactionManager in J2EE.
Jarle B. Hjortland
Chief Architect Products
Corena Norge AS
Cheers,
Marcel
