Why does jackrabbit call setAutoCommit(true)

[jarlebh <jb...@corena.no>]

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.

>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
-- 
View this message in context: http://www.nabble.com/Why-does-jackrabbit-call-setAutoCommit%28true%29-tp15086939p15086939.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Re: Why does jackrabbit call setAutoCommit(true)

[Marcel May <ma...@consol.de>]

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