Re: [SQLObject] ideas about transactions and cache

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

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.

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.

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.

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