jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister" <dominique.pfis...@day.com>
Subject Re: Caching problem with shared deployment
Date Wed, 18 Apr 2007 13:16:30 GMT
Hi Adam

On 4/18/07, Hatherly, Adam (GE Money) <Adam.Hatherly@ge.com> wrote:
> So, after lots of trial and error I added this section to the ra.xml:
>
> <authentication-mechanism>
>     <authentication-mechanism-type>SimpleCredentials</authentication-mechanism-type>
>     <credential-interface>javax.jcr.SimpleCredentials</credential-interface>
> </authentication-mechanism>
>
> Which solved that problem, although I don't know if that just works by accident
> rather than by design...

It is correct if you intend to pass login information from your web
application to the actual repository. Apparently, WebSphere assumes
BasicPassword to be the default authentication mechanism if none has
been specified.

> From that point on however, I had the transaction problem mentioned below.
>
> I then changed the ra.xml to have:
>
> <transaction-support>NoTransaction</transaction-support>
> rather than
> <transaction-support>XATransaction</transaction-support>
>
> And that seems to have solved all my problems.
> My question is - what is the implications of changing the transaction-support element,
> and why is it set to XATransaction in the example ra.xml files distributed with Jackrabbit?
> I'm sure there must be a good reason for it....

Well, the reason is the XA-capability of Jackrabbit itself, which is
probably not needed in your setup. Looking at the connector
specification, LocalTransaction is used when the application server
realizes that the overhead of using the XAResource interface is not
necessary. One can further deduce that Jackrabbit's JCA should also
support LocalTransaction, which could be easily mapped internally to
calls to the XAResource interface exposed by Jackrabbit. Looks like a
JIRA issue to me...

Kind regards
Dominique

Mime
View raw message