Ok, now say I wanted to implement the RFE I mentioned. Is there a way,
short of pessimistic locking, to ensure that no race condition occurs
when I execute:
1) Cascade delete, if successful, end
2) If failed due to constaint violation, nullify.
3) If failed for any other reason, throw exception
I'm afraid that if there are two references left and two deletes get
invoked simulatenously it is possible for both of them to end up
nullifying and the reference to be left dangling. I guess I'm looking
for table-optimistic-locking, if such a thing exists. I could achieve
this with row-optimistic-locking by adding a "references" column, but I
don't think this is required because Hibernate somehow implements this
behavior without it. Any ideas?
Gili
Andrus Adamchik wrote:
>
> On Sep 4, 2005, at 2:57 PM, Gili wrote:
>
>> I meant...
>>
>> A contains a list of B
>> B's relationship to A has a delete rule is set to "cascade"
>>
>> If I remember correctly, this is implemented by having column
>> "A_id" in each B item.
>>
>> Now, when B is deleted and it tries to cascade the operation to A
>> it'll find it can't delete it because A points to other Bs. In my
>> use-case I'd want it to then "nullify" instead of "cascade".
>
>
> Yes, a cascade rule makes no sense in the case when it points to the
> "owner". Nullify would be a correct one.
>
> Andrus
>
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Sun Sep 04 2005 - 15:21:09 EDT