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
