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,
--
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Locked
