[rucksack-devel] Conflicting Transactions: New overwrite old?

[Jochen Schmidt]

Hello,

I'm over the code of rucksack trying to implement concurrent  
transactions. I've one problem I do not seem to understand if what  
rucksack does is actually wrong or if its just a brain fart of me:

Rucksack uses an in memory cache to hold objects. untouched (clean)  
objects are hold directly in the cache until some transaction tries to  
modify it. Such modifications can occur by setting a slot on an  
persistent instance or by writing to persistent-data objects using  
PERSISTENT-DATA-WRITE. Both are the same - first the in memory object  
gets modified and then a call to CACHE-TOUCH-OBJECT moves the object  
out of the "clean objects cache" and marks it as "dirty object".

The interesting thing is that CACHE-TOUCH-OBJECT also checks if there  
is a conflict with another active transaction about this object. If  
there is an older transaction which also modified the object, a  
TRANSACTION-CONFLICT is signalled. So far so good - so the newer  
transaction should handle it by retrying later. The problem is that  
the newer transaction already MODIFIED the in memory object that is  
hold by the older transaction. The problem occurs with both - newer  
transaction who got the object from the clean objects cache or newer  
transactions who got the object from an older transaction via FIND- 
OBJECT-VERSION.

I see two solutions to this problem:

1) Do not reuse uncommited objects
Either by using cloned objects for modification or by always loading  
fresh objects from disk before modification.

2) Do the FIND-CONFLICTING-TRANSACTION check before any modification  
occurs.

I somewhat lean to the second solution, but I still hope that its all  
just a brain fart of me ;-)
Actually I think the same was reported by Леонид Новиков  
in his mail about multi-transactions and his modifications.

ciao,
Jochen


-- 
Jochen Schmidt
CRISPYLOGICS
Uhlandstr. 9, 90408 Nuremberg

Fon +49 (0)911 517 999 82
Fax +49 (0)911 517 999 83

mailto:(format nil "~(~36r@~36r.~36r~)" 870180 1680085828711918828  
16438) http://www.crispylogics.com