On 2015-02-21, 3:42 AM, "OC" wrote:
Anyway, back to the original question --
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
===
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