Tx caching

[Oliver Zeigermann]

Now that the talks come to ports to DBs like Postgres that do not do 
pessimistic locking, I have to come back to correctness of the tx 
caching. As explained before I was afraid general caching did not work 
in case the underlying store does not use pessimisctic locking. This 
fear was caused by caching having no internal locking mechanism, but has 
to rely on the underlying store to do so.

- The good news is: This is not true! This means a port to Postgres 
should not cause no new trouble :)

- The bad new is: The only isolation level tx caching can provide is 
read committed (for anyone interested I can explain this on request) :(

As for same applications this is not enough there must be a solution to 
this (certainly not for 2.x, but maybe for 2.1):

(1) Augment caching to other isolation levels
(2) Add general, short term, global, non-blocking locks per transaction
You might have guessed, I favor (2). For two reasons
- It is much easier to implement (I guess anyone could well get his/her 
PhD with (1)) and thus also would be much easier to maintain
- It would have other benefits as well, including the possibility to 
have isolation levels of the store much lower and preventing deadlocks

Just my early morning thoughts. Certainly a bit confusing. I will 
explain more on request.

Oliver



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]