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:
>>
>>>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/
>>
>
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 16:29:27 EDT