From: Steve E. (JIRA) <no...@at...> - 2006-05-31 12:19:21
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1796?page=comments#action_23212 ] Steve Ebersole commented on HHH-1796: ------------------------------------- From my understanding, yes that is the case. Although to clarify it is a "global lock" on the root node only when children (i.e. our regions) are added or removed. Manipulating data within one of our regions should not be an issue (any more than it is even with this change). > TreeCache based providers and Fqn > --------------------------------- > > Key: HHH-1796 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1796 > Project: Hibernate3 > Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.2.0 > > > Apparently we have not been using tree cache in the most proper manner in regards to Fqn construction. The way in which we construct Fqns actually leads to a very flat tree structure. For example consider a region for "org.hibernate.test.hql.Animal"; this actually leads to a tree node structured like: > /org/hibernate/test/hql/Animal > /id1 > /id2 > /... > Notice that the Hibernate region-name leads to a flat node which is a direct child of the root node... > The issue is twofold: > 1) This may be one of the causes of the high level of contention in the older pessimistic TreeCache model > 2) This is currently causing problems with the optimistic locking stuff because the "parent" node is version-incremented whenever its children is mutated (child added/removed) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |