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 <[EMAIL PROTECTED]> 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.
