Re: [SQLObject] ? Treadsafety, transactions, DB-API ?

[Bud P. B. <bu...@si...>]

On 11 Jun 2003 14:34:29 -0500
Ian Bicking <ia...@co...> wrote:

> If you *don't* use transactions, then you can be sure that each object
> is the only instance of that object (for that id) in the process.  So
> you can put locks on the object itself.

Thanks, Ian, for the clarifications.  Definitely a non-trivial
problem...

So handling single-threading, multi-processing with transactions seems
manageable with some optimistic concurrancy control in the dbms, but
multi-threading with transactions seems a real tough nut to crack...

In the latter case, one probably needs a complete transaction engine
in SQLObject (in addition to that in the dbms).  Different
transactions need to see "their" versions of objects..... or lock them
for writing until the end of the transaction......  difficult and
I'm wondering how easy it is to hide this complexity from application
programmers...

A maybe better approach would be that different threads have isolated
instances of objects (at least conceptually, and then you could have
a copy on write or similar for efficiency), their own cache (a single
instance per object in any given thread).  But that is a complicated
version of multi-processing, what advantage would the threading bring
(particularly in python where an interpreter can run only on a single
processor--if I got that correctly).  

just thinking aload hoping it's of interest to others...

-b


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------