Dirty optimistic locking

[David Schmitt]

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

[Tyler Burd]

Here is a Hibernate (java) issue that describes the problem somewhat:
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.

Hi,

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 nhu...@googlegroups.com.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

[David Schmitt]

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
>
> 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

[John Davidson]

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 <da...@dasz.at> 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

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: nhu...@googlegroups.com
[mailto:nhusers@googlegroups.com] On Behalf Of David Schmitt Sent:

Wednesday, August 03, 2011 3:59 AM To: nhu...@googlegroups.com
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 nhu...@googlegroups.com.

To unsubscribe from this group, send email to nhusers+unsubscribe@googlegroups.com.

[David Schmitt]

On 03.08.2011 21:39, John Davidson 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.

A very enlightening comment! So the problem is "only" that NH doesn't
recognize the fact that my usage is safe.

Also locking order is a -- theoretically -- solved problem if there is a
globally adhered locking order, like "always the base class/table
first." Which is what using a <version/> amounts to anyways.

Now that I have a better understanding of the problem, back to the
original question: Is there a way to get <version/> semantics with
manual control over the <version/> content?

Best Regards, David

>
> John Davidson
>
> On Wed, Aug 3, 2011 at 12:43 PM, David Schmitt <da...@dasz.at
> <mailto:da...@dasz.at>> 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: nhu...@googlegroups.com

> <mailto:nhu...@googlegroups.com>
> [mailto:nhusers@googlegroups.__com
> <mailto:nhu...@googlegroups.com>] On Behalf Of David Schmitt Sent:

> Wednesday, August 03, 2011 3:59 AM To: nhu...@googlegroups.com

> <mailto:nhu...@googlegroups.com>

> 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 nhu...@googlegroups.com

> <mailto:nhu...@googlegroups.com>.

> To unsubscribe from this group, send email to

> nhusers+unsubscribe@__googlegroups.com
> <mailto:nhusers%2Bunsu...@googlegroups.com>.

> 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 post to this group, send email to nhu...@googlegroups.com.
> To unsubscribe from this group, send email to

> nhusers+u...@googlegroups.com.

[Trinition]

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 <da...@dasz.at> 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

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: nhu...@googlegroups.com
[mailto:nhu...@googlegroups.com] On Behalf Of David Schmitt Sent:

Wednesday, August 03, 2011 3:59 AM To: nhu...@googlegroups.com
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 nhu...@googlegroups.com.

To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.