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:24:55 GMT

I am actually more than certain that these were reported against 1.3 but with
clustering enabled. Most of the problems were encountered when the customer
moved to a clustered configuration.

regards,

William


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#a13106037
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.


Mime
View raw message