.. taking to devel list ...
I've been thinking of having a Cayenne extension that would work on
top of the existing optimistic locking mechanism, but make it more
transparent to the user... Current implementation is very generic and
doesn't preclude other more specific cases to work on top of it.
Either we make it a part of Cayenne or simply describe it on Wiki in
details.
I had this discussion offline with one Cayenne users and there were
some more caveats that I can't recall now, but a custom
implementation can be done on top of vanilla Cayenne 1.1 or newer.
Just implement a "validateForInsert" method to stick the initial
version value and then implement "validateForUpdate" to compare
current value with snapshot value and increment it if it is the same
(to handle the case when multiple unsuccessful commits are done in
sequence). Anything else I am missing here?
Andrus
On Aug 29, 2005, at 4:29 PM, Gili wrote:
>
> I'll definately take a look if I can.
>
> Gili
>
> Mike Kienenberger wrote:
>
>> As I said above, we're very much in favor of offering the choices,
>> but
>> it probably won't happen until an end-user who needs it implements it
>> and submits the patches.
>> On 8/29/05, Gili <cowwo..bs.darktech.org> wrote:
>>
>>> Unfortunately, image data is part of the "uniqueness"
>>> definition in my
>>> table. An image also has a hashcode associated with it so what I
>>> first
>>> do is compare hashcodes and only if the hashcode matches do I
>>> compare
>>> the full data stream.
>>>
>>> With Hibernate, I only compare data fields when inserting
>>> a new image
>>> into the table (to ensure I'm not inserting the same image
>>> twice). Once
>>> inserted, I assume optimistic locking will detect update
>>> collisions but
>>> do so without having to compare the entire data field.
>>>
>>> For my particular use-case, the performance benefit of
>>> versioning-based
>>> optimistic locking far outweighs the danger of external
>>> modification. I
>>> make sure to only manipulate the values using applications
>>> stacked on
>>> top of the ORM.
>>>
>>> With your permission, I'd like to file a RFE for version-
>>> based
>>> optimistic locking and hopefully we can offer users a choice
>>> between the
>>> two methods.
>>>
>>> Gili
>>>
>>> Mike Kienenberger wrote:
This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 16:36:18 EDT