Chuck,
On 21. 2. 2015, at 20:09, Chuck Hill <ch...@gevityinc.com> wrote:
> I think it is a fair expectation that EOF may not properly support optimistic
pessimistic, I guess?
> locking. I am not even sure how to set it up properly. There are some
> methods on EOEditingContext and EODatabaseContext, and one the
> EODatabaseContext Delegate.
Thanks!
One closely related question -- I suppose there is no way to explicitly set up
the isolation level and locking discipline for a particular transaction
(differently from the default of the JDBC connexion URL)? Or is there one?
Thanks again and all the best,
OC
> On 2015-02-21, 3:42 AM, "OC" wrote:
>
> Anyway, back to the original question --
>
> On 20. 2. 2015, at 18:27, OC <o...@ocs.cz> wrote:
> Actually _this_ should not be weird, this should be quite a normal code; the
> only requirement is that check-and-save, i.e., conceptually,
> ===
> if (TEST(eo.someRelationship().someAttribute(),newAttributeValue)) {
> def
> new=EOUtilities.createAndInsertInstance(eo.editingContext(),'SomeRelationshipTarget')
> new.someAttribute=newAttributeValue
> eo.editingContext().saveChanges()
> }
> ===
> so that I can be absolutely sure that nobody stores an attribute value which
> -- at the moment of COMMITTing the appropriate INSERT -- would not pass the
> TEST
>
> I don’t think you can make a rock-solid guarantee from the app code level.
> Can't I? That's bad.
>
> -- I have succeeded to consult with my client, and the option of „allowing to
> save any bid, determine whether it was valid or not in future“ is out.
>
> On the other hand, he again suggests pessimistic locking: „why don't we
> simply lock the auction row when user reads the data to determine whether his
> bid is valid, and unlock when he saves the valid bid or when he determines
> the bid is not valid“?
>
> I can see only one slight drawback -- unnecessary locks in case the bid
> validation fails -- but that should be a negligible problem, most bid
> attempts are valid (and _if_ they become invalid, then since other bid was
> entered shortly before, which would lead to optimistic exception anyway).
>
> Far as I understand though based on your
>
> ===
> On 24. 1. 2015, at 0:12, Chuck Hill <ch...@gevityinc.com> wrote:
> I doubt that lockObject() code in EOF has been run in… maybe forever. It is
> highly possible that it is causing EOF to get confused and resulting in the
> errors below. Get rid of the lockObject() calls and see if the problem below
> goes away.
> ===
>
> I guess the proper answer is „Well we can't use pessimistic row locking at
> all, since EOF does not support it reliably, and that's that.“
>
> Is that right?
>
> Thanks again,
> OC
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
