Your reply has shed some light on a deadlock I'm experiencing. I'm requesting LockMode.Upgrade on my entity, but my entity is a subclass that spans a base-class table and subclass-table. The upgrade lock is grabbed only on the base table while the subclass table only gets a shared lock. But later, when the transaction is committing, the it's trying to grab an exclusive lock on the subclass table, but can't because another thread has a shared lock on the subclass.
I think in my situation I may need to get a more aggressive lock up front to block the competing shared locks. On Wednesday, August 3, 2011 3:39:56 PM UTC-4, jwdavidson wrote: > > Think about database concurrency with a joined-subclass and the parent > class. One transaction could lock the subclass and its parent. A second > user transaction could lock a second subclass and the same parent, causing > a deadlock. For that reason locking is not supported for the subclass. > > This has nothing to do with the property changing type and everything to > do with the locking on a subclass. > > John Davidson > > On Wed, Aug 3, 2011 at 12:43 PM, David Schmitt <[email protected]<javascript:> > > wrote: > >> On 03.08.2011 18:01, Tyler Burd wrote: >> >>> Here is a Hibernate (java) issue that describes the problem >>> somewhat: >>> https://hibernate.onjira.com/**browse/HHH-2242<https://hibernate.onjira.com/browse/HHH-2242> >>> >>> From the issue: "However, the two property-based optimisitc locking >>> schemes (all& dirty) are conceptually not correct with >>> joined-subclasses. We could relax that if we enforced that all >>> properties actually used in optimistic locking occurred in the "base >>> table". But thats not worth the effort." >>> >>> I'm not sure why they are "conceptually not correct", but it sounds >>> like you just can't use "dirty" optimistic locking if you are using >>> joined-subclasses in Hibernate, and I assume that applies to >>> NHibernate as well. >>> >> >> I'm wondering about that too. Especially as I'm really replacing a >> <version/> mapping with a single "dirty" property (even of the same >> underlying db type). So "conceptually" nothing should change. >> >> >> :-/ >> >> Best Regards, David >> >> >>> >>> -----Original Message----- From: [email protected] <javascript:> >>> [mailto:nhu...@googlegroups.**com <javascript:>] On Behalf Of David >>> Schmitt Sent: >>> Wednesday, August 03, 2011 3:59 AM To: [email protected]<javascript:> >>> Subject: [nhusers] Dirty optimistic locking >>> >>> Hi, >>> >>> I'm trying to implement a<version/> mapping without NHibernate >>> doing the automated version increment. This is because I need to have >>> very fine-grained control over the version, e.g. when transporting >>> objects between databases. >>> >>> I've converted all my<version/> mappings into plain properties with >>> optimistic-lock="true", while setting all other properties to >>> optimistic-lock="false". The classes all received >>> dynamic-update="true" and optimistic-lock="dirty". Sadly, I'm now >>> hitting "MappingException: optimistic-lock=all|dirty not supported >>> for joined-subclass mappings." >>> >>> I'm wondering if there is an easier way to get this behaviour. Else >>> I guess I'll have to take this to the -dev mailing list, since I do >>> not fully understand why dynamic-update would be required and >>> why<version/> would work where the same mapping semantics with a >>> simple<property/> would not work. >>> >>> >>> >>> Thanks in advance, David >>> >>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "nhusers" group. >> To post to this group, send email to [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to nhusers+u...@** >> googlegroups.com <javascript:>. >> For more options, visit this group at http://groups.google.com/** >> group/nhusers?hl=en <http://groups.google.com/group/nhusers?hl=en>. >> >> > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To view this discussion on the web visit https://groups.google.com/d/msg/nhusers/-/2X3E91xDZfIJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
