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:
> Note that you can pick and choose your optimistic locking fields.
> If you don't need to compare the blob to guarantee "uniqueness" (for
> whatever that means to your application), then don't set it as an
> optimistic locking field.
>
> This can also allow you to simulate timestamp or versioning manually,
> or we'd happily accept patches to support versioning or timestamping
> seemlessly. :)
>
> Again, though, it's not optimistic locking that's requiring the
> backing caches. OL simply makes use of what's already there.
> (Actually, maybe OL does require an additional retained cache you
> might be able to drop -- I can't remember).
>
> -Mike
>
> On 8/29/05, Gili <cowwo..bs.darktech.org> wrote:
>
>> I have a table "image" in my database. One of the columns is a blob for
>>containing the image data (500k to 2MB). Using the current approach, not
>>only will memory usage be extremely high but also commiting will be
>>extremely slow because we'll have to now compare the value of the blob.
>>I don't think adding streaming blobs will help here either because the
>>current optimistic locking mechanism requires us to read and compare the
>>full contents of the field anyway.
>>
>> Yes, I see your point regarding the danger if the table is modified
>>using an external tool but I guess the assumption is that the
>>performance benefits of version-based optimistic locking far outweigh
>>the potential safety issues. You just have to ensure to use your ORM for
>>all your transaction or if you decide on using "unsafe" operations
>>(SQLTemplate or other external methods) you must be aware of the
>>potential consequences.
>>
>> It is likely we're coming at this from different requirements though.
>>I'm really concerned about scalability issues with Cayenne because I
>>plan on dealing with a massive amounts of images streamed from my DB
>>while your average webapp operations do not involve this amount of data.
>>
>>Gili
>>
>>Gentry, Michael (Contractor) wrote:
>>
>>>Well, I personally prefer the way Cayenne does optimistic locking. I
>>>don't want to lock on a meaningless piece of data. Let's face it, which
>>>data is most important, the user-entered purchasePrice or somewhat
>>>arbitrary recordVersionNumber? It is far to easy to update a record (in
>>>a production support role or external database utility, etc) and forget
>>>to increment the version, which could have bad consequences as a result.
>>>
>>>In your "flush to database" comment, that's where you would be doing a
>>>dataContext.commitChanges(). This starts a transaction, flushes changes
>>>to the database, and ends the transaction. At this point, assuming it
>>>succeeded, the dataContext is in sync with the database. Rolling back
>>>from here shouldn't really doing anything (you are back as far as you
>>>can go). With nested data contexts (not sure how close this is to being
>>>functional), you'll be able to commit changes in a child data context to
>>>a parent data context, which will still allow you to rollback the parent
>>>to the pre-commit of the child changes (I think -- Mike/Andrus correct
>>>me if I am wrong there).
>>>
>>>There's not a lot here, but perhaps it would help a bit?
>>>
>>>http://www.objectstyle.org/confluence/display/CAY/Optimistic+Locking+Exp
>>>lained
>>>
>>>Caching the original database value is pretty important to how this
>>>works. Yes, it takes more memory, but is vastly more safe.
>>>
>>>/dev/mrg
>>>
>>>
>>>-----Original Message-----
>>>From: Gili [mailto:cowwo..bs.darktech.org]
>>>Sent: Monday, August 29, 2005 2:32 PM
>>>To: cayenne-use..bjectstyle.org
>>>Subject: Why don't we use version-based optimistic locking?
>>>
>>>
>>>Hi,
>>>
>>> Just curious why we chose to implement optimistic locking like
>>>we did.
>>>The reason I ask is that I want to be able to:
>>>
>>>add 1000 objects
>>>flush to database
>>>add 1000 objects
>>>...
>>>many objects later...
>>>dataContext.commit()
>>>
>>> now, I should be able to dataContext.rollback() at any time and
>>>this
>>>should undo all changes all the way back to the beginning of the
>>>context. I've been talking to Mike on IRC and he says that to his
>>>knowledge it is unlikely we can implement the above behavior because
>>>right now optimistic locking caches the original attribute value so that
>>>
>>>at commit time we can compare it to the DB version and throw an
>>>exception if optimistic locking failed. This incurs heavy memory usage.
>>>
>>> Now, if we were only remembering a version/timestamp per row, it
>>>would
>>>be much easier to implement this. I ask because Hibernate can already
>>>support this behavior using this code:
>>>
>>>// execute 1000 times
>>>session.saveOrUpdate(object);
>>>...
>>>session.flush();
>>>session.clear();
>>>...
>>>// many objects later
>>>...
>>>session.commit() or session.rollback() will go all the way past the
>>>session.flush()/clear() calls.
>>>
>>> I am sorry for all these questions but I am rather new to all of
>>>this :)
>>>
>>>Thank you,
>>>Gili
>>
>>--
>>http://www.desktopbeautifier.com/
>>
>
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 16:17:25 EDT