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

[Arthur Lemmens]

Jochen wrote:

> I'm using here a modified variant of rucksack in which I added a GF
> CACHE-PREPARE-MODIFICATION.
> This GF is called in every place were rucksack tries to modifiy objects:
>
> 1) Setting slots of instances of RS:PERSISTENT-CLASS
> 2) RS:P-REPLACE
> 3) RS::PERSISTENT-DATA-WRITE
> 4) SLOT-MAKUNBOUND on instances of RS:PERSISTENT-CLASS
> 5) UPDATE-INSTANCE-FOR-REDEFINED-CLASS
>
> CACHE-PREPARE-MODIFICATION currently checks for conflicts and signals
> an error if there is one.
> I removed the conflict check from CACHE-TOUCH-OBJECT.

Sounds good to me.


> I then implemented a new rucksack subclass which uses a shared reader/
> exclusive writer transaction scheme.
> This is currently done on the transaction level - one decides if one
> wants an "exclusive transaction" or a "shared transaction". I use an
> own implementation of shared-locks so that an exclusive transaction
> will wait for all running shared transactions to end but shared
> transactions can always join their kinds.

So if two shared transactions try to modify the same object your
CACHE-PREPARE-MODIFICATION function will signal an error, right?


> Other exclusive transactions and shared transactions will wait for the
> one running exclusive transaction of course. This actually seems to work
> quite well in one of my web application servers which creates one shared
> transaction per request. This enables parallel request processing in this
> case.

Interesting.  Sounds like a good approach for many web apps.


>> Yes, this sounds like the best solution to me.  In terms of the above
>> scenario, that means that we signal an error before step 4 actually
>> happens.
>
> Or clone a new transaction local object for the transaction. Of course
> this actually would only work when taking a dependency journal between
> transactions. If T1 in the above example would get rolled back one
> could not commit T2. If T1 is not yet committed T2 would have to wait
> for it. I think this would actually involve all those 2-phase-commit
> protocol stuff including the demand for a lock manager that resolves
> dead locks.

Right.  Thanks for the detailed analysis.

Arthur