Re: [SQLObject] Expiring Cache

[Sidnei da S. <si...@aw...>]

On Mon, Oct 27, 2003 at 03:16:51PM -0600, Ian Bicking wrote:
| I think there's maybe some confusion about the different objects.
| 
| First, caching happens per-connection.  Which means each transaction 
| has its own cache, if you are using transactions.  If you create an 
| object by a certain ID in a transaction, any attempt to get that object 
| by that ID from the same transaction will give you back the same object 
| you got before, guaranteed.  But in a different transaction you will 
| get a different object, since the two transactions are isolated.

Ok, I think I'm starting to understand what fits where now. I think
that the problem is that I was using the same connection for different
transactions here. 

| It just occurred to me there's some sloppiness when it comes to 
| committing or rolling back a transaction.  The objects stick around, 
| but once you've finalized the transaction I don't know what use they 
| are.  Those instances should actually be invalid.  Unless you assume 
| that by committing or rolling back a transaction, you are implicitly 
| restarting the transaction and can keep using it.  Anyway, I don't 
| think this applies to this circumstance, but it should be worked out.

If by 'those instances' you mean the instances involved in the current
transaction, I think that there are two cases, assuming that
both commit and rollback start a new transaction implicitly, which I
think it's a good thing (albeit a bit magical):

1. The transaction is rolled back, the objects are in invalid state
and should be purged from cache
2. Transaction is commited, the objects are valid and the cache is
valid. 

| So -- attributes changes immediately update the database.  They also 
| update the internal cache of that column.  Other instances that are in 
| other transactions are not effected.  They aren't effected when you 
| commit the transaction.  It seems like at some point they should be 
| effected (expired, perhaps), but I'm not sure where.

Ok, so this is what I had in mind, and where it starts getting
tricky. A situation like this would cause a conflict error in ZODB:

- transaction 1 starts, with object x
- transaction 2 starts, with object x
- transaction 1 changes object x and commits
- transaction 2 changes object x and tries to commit
- before commiting the state of object x from transaction 2 is 
  tested against the object commited and its detected that the 
  state changed during transaction 2
- a ConflictError is raised

AFAICS, in the current implementation, the state of 'x' from
transaction '2' would override the state of 'x' as saved by
transaction '1'. Does that sound correct? 

<snip dubious cache interpretation :) />

| SQLObject should already handle this, at least for an individual 
| instance.  It knows when you change an attribute and updates its own 
| cache.

Ok, so based on this, and on the fact that there is a cache per
connection, and another for transaction, is it safe to assume that as
long as I have *exactly* one and *the same* connection being used
during a single transaction, creating an SQLObject instance multiple
times should have minimal effect on performance? I feel like  I've been
doing a lot of confusion with connections x transactions x instances.

| I imagine ObjectModified is meant for something like ZODB, where 
| persistence is added more transparently to an instance (the expense 
| being that something must be watching the instance and telling it when 
| it's been changed).  I think SQLObject can ignore that message, as 
| instances are self-aware.

Yes, I think you're right here, except if the case about conflicts
above holds true.

-- 
Sidnei da Silva <si...@aw...>
dreamcatching :: making your dreams come true
http://awkly.org

/earth: file system full.