[SQLObject] Re: ideas about transactions and cache

[Cyril E. <cy...@de...>]

Ian Bicking wrote:
> Cyril Elkaim wrote:
> 
>> Use a _common_ cache and remove the DBMS pool from the dbconnection, 
>> each one connect to the DBMS once instanciated and maintains it opened 
>> during its lifetime. BTW, I think that it would be interesting to have 
>> only Transaction connections and let the user apply begin and commits 
>> when necessary. If necessary a client code can instanciate as many 
>> connections as necessary (as we already do). In this way every 
>> modification done by a connection will be reported back to the 
>> _common_ cache and  everybody will see the changes.
> 
> 
> I'm not sure I understand this completely.  But let's see...
> 
> First, what I believe to be the current behavior.
> 
> Anytime you commit a transaction, all the objects in the parent 
> transaction are expired.  Anytime you rollback all objects in the 
> transaction are expired.  This leaves out what I think you want: when 
> you commit, you want all objects in *other* transactions to expire.
> 

What's happen actually is, when you commit a rollback a transaction, 
it's _own_ cache is updated but _not_ the cache of its parent 
connection. If I've read the code correctly the parent's cache is never 
modified. A simple solution is, of course, to instanciate a Transaction 
object at the start of the application and never use its 'standard' 
parent connection. This is what we do and that works.

But if we want multiple users to make transactions it can't be used. The 
problem is that the DBMS must maintains the same connection during a 
transaction lifetime and the connection pool (that is now shared by all 
our sessions because we have now one Transaction) in dbConnection cannot 
guaranty that.

> Another way of thinking of it that I'd like, but may be hard to 
> implement, is a hierarchy of caches and connections.  When a transaction 
> is started, it has an empty cache.  On a fetch, it checks its parent's 
> cache, and if necessary adds to its parent's cache.  When it modifies 
> the object, it writes to its personal cache.  When it rolls back, it 
> deletes from its personal cache.  When it commits, it writes its 
> personal cache to its parent's cache.
> 

Seems to be a good concept and what i am beginning to work on.

Just a question, why is it necessary to have a separate Transaction 
class? Shouldn't be possible to have only the dbConnection and use it in 
Transactionnal mode if we want for example?

> Though the objects being cached couldn't be SQLObject instances, they'd 
> have to be record sets.  Each transaction would still have its own 
> instance.
> 
> Would that fit what you are thinking of?  A more expedient solution 
> would be for transaction commits to expire objects in other 
> transactions.  Well, with a bit of care, but something like that.
> 

Yes. but we must now have a ConnectionSet, or something like that, and 
create new dbConnection objects through this object, just an idea.


Cyril Elkaim