jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Is this issue resolved?
Date Mon, 08 Oct 2007 22:14:59 GMT
Hi,

On 10/9/07, William Louth <william.louth@jinspired.com> wrote:
> The tone reflects my frustration at having to go over this time and time
> again. I might as well be talking to the wall when it comes to Jackrabbit.

I'm sorry for that. Thanks anyway for following up on this, as your
input is very valuable, even if we've failed to show that.

> I did indicate there was one issue which I subsequently deemed dubious and
> possibly an incorrect assessment by the tool but the all other issues (4-5)
> were valid. We can all make mistakes but to continue to imply an assessment
> by a person who has worked many years in building tools for transaction
> processing analysis was incorrect is unacceptable and irresponsible to
> potential customers.

I don't doubt your experience, in fact I'm quite certain you are far
more experienced with transactions than I will ever be. See below for
a more detailed review of the points you raised on your posts about
Jackrabbit.

1) http://blog.jinspired.com/?p=37

The first warning you discuss is about the SQL statement "UPDATE
CLUSTER_GLOBAL_REVISION SET revision = revision + 1", where JXInsight
warns that the UPDATE statement is executed before reading anything
from the same table. However, the current value of the global revision
counter is actually read in the right hand side of the SET expression,
making previous SELECT statements unneeded.

The other warnings are about DELETE and UPDATE statements on the
default_prop and default_node tables where no SELECTs on those tables
have been made within the same transaction. This would likely be a
problem in a typical database environment where there are multiple
concurrent clients accessing and modifying the data, but in
(non-clustered) Jackrabbit all database access for a workspace happens
through a single connection in the a database persistence manager
configured for that workspace. Thus there is no need for Jackrabbit to
read the data _during the same transaction_ before deleting or
updating it.

Now, and this may well be a big problem in Jackrabbit, in clustered
mode Jackrabbit actually does allow multiple clients to concurrently
access and modify the underlying database. There is a separate
clustering journal that is used to synchronize the cluster nodes, but
I'm not too certain that all the race conditions are properly
accounted for. I'll branch a separate thread for the details.

2) http://blog.jinspired.com/?p=39

This problem is about two threads using a prepared statement within
the context of the same transaction. Looking deeper into the issue I
think I've identified the cause in DatabaseJournal in Jackrabbit 1.2.x
operating with autocommits disabled but without proper commit() calls
to separate the transactions. There is no need for the operations in
question to execute within the same transaction boundary, so in
Jackrabbit 1.3.x the autocommit mode is enabled.

William, I must admit initially misjudging this blog entry based on
looking only at the Jackrabbit 1.3 code (still the trunk at the time).
I couldn't find any place where such cross-thread transaction access
could occur, so I assumed (incorrectly extrapolating from the false
positives on the first blog post) the tool to have just flagged the
Jackrabbit practice of acquiring a single connection and preparing all
required statements, and then using those statements from multiple
(synchronized) threads.

3) http://blog.jinspired.com/?p=40

This is another case of multiple threads operating using the same
transaction, and I believe the root cause is the same incorrect
autocommit setting in Jackrabbit 1.2.x.

> Also one look at a few tx related issues in the jira tracking systems
> reveals fatal flaws in the transaction handling of jcr session level
> operations.

You mean JCR-449 and JCR-566? These are both related to versioning,
and due to architectural constraints in Jackrabbit (versioning store
being referenced by multiple workspaces) we have trouble ensuring
properly transactional (or even concurrent, at least up to Jackrabbit
1.3.3) access to the versioning features.

However, normal level 2 operations should work fine with transactions
in Jackrabbit.

BR,

Jukka Zitting

Mime
View raw message