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
