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/
This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 15:57:21 EDT