Testing with Websphere 6.1 & Oracle 11g

[Serge Huber <sh...@jahia.com>]

Hi Jackrabbit developers,

I have been quite passive on this list for a long time, but I have finally
been able to work with Jackrabbit a bit more, and I really need your help at
this point :)

I have been trying to deploy Jackrabbit on one of the most unforgiving
platforms : Websphere 6.1 and Oracle 9/10/11g. I have struggled quite a lot,
and I had to revert to webapp-based deployment because the JCA deployment
model just didn't fit well with the software I'm trying to integrate with (I
was having issues with the authentification&authorization that was not
possible to integrate into the connector).

I managed to make most of it work, but I am now facing an issue that looks
like an architectural issue, which is why I am writing here. Basically the
problem I am seeing is that Websphere is complaining about accessing JNDI
resources outside of container-managed threads. In the specific case I am
investigating, this happens in the ObservationDispatcher class, that creates
a thread for handling the notifications. Websphere refuses to serve the
managed datasource because the threads are not managed by him.

>From my point of view I have the following options :
- directly connect Jackrabbit to the database, without using the container
datasource and using JDBC connections
- modifying the thread creation in Jackrabbit to maybe use something like
the CommonJ Workmanager interface that allows the creation of contained
managed threads

The first solution I keep as a last solution, because I think that clients
using Websphere will not like the idea of having JDBC connections that they
have no control over. So I'd prefer to work on the thread creation part, but
here I have the problem that the ObservationDispatcher class, from what I
could understand of the source code, is not pluggeable so I couldn't replace
it without really patching the code.

Does this analysis look right ? Did I miss something ?

I should point out that I am more than willing to do whatever work could
help this issue out, as I am under a rather aggressive timeline to make all
of this work.

Best regards,
  Serge Huber.

Re: Testing with Websphere 6.1 & Oracle 11g

[Serge Huber <sh...@jahia.com>]

Hi Jukka,
Thank you for the quick reply.

I will take a stronger look at the first option then :)

Regards,
  Serge Huber.

On Tue, Apr 14, 2009 at 10:33 AM, Jukka Zitting <ju...@gmail.com>wrote:

> Hi,
>
> On Tue, Apr 14, 2009 at 9:13 AM, Serge Huber <sh...@jahia.com> wrote:
> > From my point of view I have the following options :
> >
> > - directly connect Jackrabbit to the database, without using the
> container
> > datasource and using JDBC connections
> >
> > - modifying the thread creation in Jackrabbit to maybe use something like
> > the CommonJ Workmanager interface that allows the creation of contained
> > managed threads
> >
> > The first solution I keep as a last solution, because I think that
> clients
> > using Websphere will not like the idea of having JDBC connections that
> they
> > have no control over.
>
> On the other hand Jackrabbit doesn't like JDBC connections that it
> doesn't have full control over. For example, mixing a Jackrabbit
> transaction and a container-managed database transaction is a bad
> idea. Also, Jackrabbit likes to keep long-lived database connections
> and switch them back and forth from auto-commit mode, which are both
> operations that some container-managed data sources don't like that
> much.
>
> So, from a technical perspective your path of least resistance would
> clearly be to go with the first option.
>
> BR,
>
> Jukka Zitting
>

Re: Testing with Websphere 6.1 & Oracle 11g

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Apr 14, 2009 at 9:13 AM, Serge Huber <sh...@jahia.com> wrote:
> From my point of view I have the following options :
>
> - directly connect Jackrabbit to the database, without using the container
> datasource and using JDBC connections
>
> - modifying the thread creation in Jackrabbit to maybe use something like
> the CommonJ Workmanager interface that allows the creation of contained
> managed threads
>
> The first solution I keep as a last solution, because I think that clients
> using Websphere will not like the idea of having JDBC connections that they
> have no control over.

On the other hand Jackrabbit doesn't like JDBC connections that it
doesn't have full control over. For example, mixing a Jackrabbit
transaction and a container-managed database transaction is a bad
idea. Also, Jackrabbit likes to keep long-lived database connections
and switch them back and forth from auto-commit mode, which are both
operations that some container-managed data sources don't like that
much.

So, from a technical perspective your path of least resistance would
clearly be to go with the first option.

BR,

Jukka Zitting