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/
>
This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 16:05:08 EDT