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:
> > 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:25:02 EDT