Re: [SQLObject] Re: ideas about transactions and cache

[Ian B. <ia...@co...>]

Sorry I took so long to reply...

Cyril Elkaim wrote:
>> 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.

Yes, when I look at the code I see that is true.  I really meant to do 
it the right way, but I guess I never actually implemented it.

> 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.

Each Transaction is bound to a single database connection.  That's most 
of what Transaction actually does, by kind of dynamically overriding 
query, queryAll, queryOne, and queryInsertID to use its own database 
connection instead of a connection from the pool.

>> 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?

Well, there has to be some object that indicates which transaction the 
object is part of.  This object is a connection currently, because that 
was most obvious since DB-API connections and transactions are bound to 
each other.  It probably makes more sense for transactions and 
connections to be entirely separate.  Another way of phrasing this might 
be an "editing context" (I think Modeling uses that term), which is a 
transaction (along with a cache and some other stuff).

>> 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.

Hmm... I'm not following.  Though it may be because "connection" is 
being used too many times.  What would ConnectionSet do?

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org