jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Louth <william.lo...@jinspired.com>
Subject Re: Is this issue resolved?
Date Mon, 08 Oct 2007 22:22:56 GMT


"CLUSTER_GLOBAL_REVISION SET revision = revision + 1"

Yes this was the case I mentioned were JXInsight had incorrectly classified
the transactional behavior but there I do believe that this was a mistake in
the blog entry and that on another table there was a similar update of a
sequence without the read within the statement itself. I believe we have
archived the snapshot so I should be able to come back with the actual
offending statement this week. 

I am not certain but I believe the issues were all reported with 1.2 up-to
(and maybe including) 1.3. I will check back with the customer.



Jukka Zitting wrote:
> 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

View this message in context: http://www.nabble.com/Is-this-issue-resolved--tf4561381.html#a13106034
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.

View raw message