BTW: discarding the object if it already exists on insert is not an
option. Perhaps my example was no good. Here is an actual use-case from
my software.
ImageProvider[email, name, homepage] - email = unique
So, if at commit time I discover that an object already exists with the
specified email, throwing away my new object is a mistake because I
might have modified the value of name or homepage and I'd want the
existing object to be updated with those values.
The more I think about it, the more I think this might be beyond the
scope of Cayenne. It sounds like it should be up to me to catch the
constraint violation and retry the entire transaction. One thing though,
I'd want Cayenne to be able to tell me whether the constraint violation
was due to an insert vs an update without having to parse the exception
message. Is it possible to modify it to throw two different exceptions?
To me, an insert exception is recoverable (retry the transaction) vs an
update exception indicates a bug in my code because if optimistic
locking says the table hasn't been updated by an external program and I
*still* somehow managed to violate constraints then it must be that my
code did something wrong.
Gili
Gili wrote:
>
> Optimistic locking only operates over a row, right? Not an entire
> table...
>
> I think maybe what I have to do is find out which columns are used
> by getCanonicalInstance() and flag them as unique, then my current
> implementation is guaranteed to not run into race conditions. The only
> problem now is that if a race condition occurs my code will get a
> constraint violation exception instead of a optimistic locking
> exception. When the latter occurs my code would retry. When the former
> occurs it is flagged as a bug and I don't handle the exception.
>
> There needs to be a way for me to flag the former as a recoverable
> operation. I'm not sure how.
>
> Gili
>
> Mike Kienenberger wrote:
>
>> You'd have to do the same thing in Cayenne, or another workaround (try
>> to insert the object and throw it away if you get a constraint
>> violation exception). You're going to have race conditions if you
>> check, then create, then insert. That said, I have used the same
>> process.
>>
>> I wonder if a better workaround might be to create a psuedo-optimistic
>> lock on your unique keys.
>>
>> On 9/3/05, Gili <cowwo..bs.darktech.org> wrote:
>>
>>> Hi,
>>>
>>> Say I have:
>>>
>>> table ImageSpecification [id, width, height]
>>>
>>> In Hibernate if I created a new ImageSpecification in my
>>> application
>>> and I wanted to save it into the database only if it didn't already
>>> exist (i.e. canonicalization) I would have to manually invoke something
>>> like this:
>>>
>>> mySpecification = mySpecification.getCanonicalInstance()
>>>
>>> where getCanonicalInstance() is a method I implemented to
>>> issue a DB
>>> query and if an equivilent object was found in the DB return it;
>>> otherwise return "this". In this way I would ensure that I never ended
>>> up with two copies in the database of the same specification.
>>>
>>> Would I have to do the same with Cayenne or is there a cleaner
>>> way?
>>>
>>> Thank you,
>>> Gili
>>> --
>>> http://www.desktopbeautifier.com/
>>>
>>
>>
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Sat Sep 03 2005 - 21:42:37 EDT