Hello Marten,
a simple but effective strategy could be to include something
like theEmptySet add: #deleted in transaction A. This would
conflict with a potential addition made by transaction B. As far
as I understand your use case, the Set-Entry #deleted (or
whatever) won't be a problem if no conflict occures, since the
object with the Set will be GCed in that case.
Br,
Ralph
I do not want to remove an empty set from an object, perhaps this makes it much clearer:
Transaction A:
+-------------------> check if set in object attribute slot is empty -> remove object -> ------------------------------------+
Transaction B:
+ -----------------> add element to set in object attribute slot -> ------------ +
I would not assume, that this results into a commit conflict ....
James Foster [hidden email] hat am 27. Februar 2019 um 15:59 geschrieben:
In order to better understand the situation, I have two questions:(1) Why do you want to remove an empty Set from an object?(2) Why not use locks?
James
On Feb 27, 2019, at 4:16 AM, Marten Feldtmann via Glass < [hidden email]> wrote:
_______________________________________________This seems to be a general concurrency handling pattern in Gemstone:
Situation: I have an object, which holds a Set in one of its attributes (slots).
Question: I want to remove this object, IF the set is empty. But what happens, if another task is just adding an item to this set ? How can Gemstone find a commit conflict ? I do not want to use locks on objects.
Any other idea ?
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass
| Free forum by Nabble | Edit this page |