[Glass] How can I solve this kind of commit conflict?

[Mariano Martinez Peck via Glass]

Hi, I am reading the Programming Guide manual to solve my issue but I would
like to double check with you as these things takes time to debug.

*Scenario*: multiple background jobs (each on a separate gem) may write a
"lastSaveTimestamp" with "DateAndTime now" when they write into my logic DB
concept. So, obviously, right now I am having commit conflicts on it.

*What I want*: I want that my gems simply get a mutex on
""lastSaveTimestamp"  instVar of that class. If other sessions ask for it,
make them wait. As soon as I am done changing the value, then release lock.

*Code*:

FaDataStore  >> initialize
    super initialize.
     lastSaveTimestamp := ValueHolder new.


FaDataStore >> lastSaveTimestamp: aDateAndTime
System waitForApplicationWriteLock: lastSaveTimestamp queue: 1 "I just pick
1 randomly" autoRelease: false.
[
lastSaveTimestamp contents: aDateAndTime.
] ensure: [ System removeLock: lastSaveTimestamp ]


Does that sound good? Because I am not sure it solves my commit conflicts.
Imagine I have 2 jobs that were both started with a "nil" timestamp.
Imagine this sequence:

1) both process were launched with the same view of the repo, none commit
from any of those 2 yet.
2) process A grants lock and writes time XXX
3) now process B ask for lock (it might have to wait for A to finish) and
writes YYY to the object.
4) Now B commits.
5) Now A tries to commit. Wouldn't I have a commit conflict here anyway?
Because A will try to commit the value XXX (which changed from nil) while B
already committed YYY.

how can I solve this?

Thanks in advance,


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170628/ff51b9d9/attachment.html>