You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2008/06/25 12:44:45 UTC
The concurrent library (Re: Locking issues with XAItemStateManager - help appreciated)
Hi,
[Moving the thread to dev@]
On Wed, Jun 25, 2008 at 1:31 PM, sbarriba <sb...@yahoo.co.uk> wrote:
> ...and as an aside I note from
> http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
> That concurrent 1.3.4 is now in maintenance mode.
> Is there a plan to move to java.util.concurrent within the JDK?
Jackrabbit is currently (mostly) based on Java 1.4, that doesn't yet
have the java.util.concurrent library.
There's the backport-util-concurrent library [1] that we could
(should?) migrate to before upgrading to Java 5.
However, last time I checked the required Jackrabbit modifications are
not trivial (some of the classes and semantics in concurrent 1.3.4 are
different from java.util.concurrent) so unless someone wants to
scratch that itch and provide a good patch for this I'm inclined to
stick with the what we have now.
[1] http://backport-jsr166.sourceforge.net/
BR,
Jukka Zitting
Re: The concurrent library (Re: Locking issues with XAItemStateManager - help appreciated)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Jun 25, 2008 at 4:04 PM, KÖLL Claus <C....@tirol.gv.at> wrote:
> moving to dev list ...
I only meant to move the tangent about the concurrent library (see the
subject), not the original locking issue faced by the user.
BR,
Jukka Zitting
AW: The concurrent library (Re: Locking issues with XAItemStateManager - help appreciated)
Posted by KÖLL Claus <C....@TIROL.GV.AT>.
Hi Shaun,
moving to dev list ...
In my case the problem was that the applicationserver (websphere)
has changed the thread between acquiring writelock and the downgrade to a readlock
so we are running into deadlock.
Have you tested the patched DefaultISMLocking Class ?
>Hi Claus,
>Thanks for the quick response.
>
>We're not intentionally using an XA transaction. We're using Spring +
>Transaction Manager + Hibernate elsewhere to satisfy the request.
>
>....so a few quick questions:
>
>* Is there a way to force JackRabbit not to use XA? What are the alternative
>ItemStateManager(s)?
>* Does using XA cause more locking?
>
>Thanks in advance,
>Regards,
>Shaun
-----Ursprüngliche Nachricht-----
Von: Jukka Zitting [mailto:jukka.zitting@gmail.com]
Gesendet: Mittwoch, 25. Juni 2008 12:45
An: dev@jackrabbit.apache.org
Betreff: The concurrent library (Re: Locking issues with XAItemStateManager - help appreciated)
Hi,
[Moving the thread to dev@]
On Wed, Jun 25, 2008 at 1:31 PM, sbarriba <sb...@yahoo.co.uk> wrote:
> ...and as an aside I note from
> http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
> That concurrent 1.3.4 is now in maintenance mode.
> Is there a plan to move to java.util.concurrent within the JDK?
Jackrabbit is currently (mostly) based on Java 1.4, that doesn't yet
have the java.util.concurrent library.
There's the backport-util-concurrent library [1] that we could
(should?) migrate to before upgrading to Java 5.
However, last time I checked the required Jackrabbit modifications are
not trivial (some of the classes and semantics in concurrent 1.3.4 are
different from java.util.concurrent) so unless someone wants to
scratch that itch and provide a good patch for this I'm inclined to
stick with the what we have now.
[1] http://backport-jsr166.sourceforge.net/
BR,
Jukka Zitting