[TransWarp] CIS and Threaded Apps

[Ulrich Eck]

> Just a reminder: as I said previously, the Database package will see
> *heavy* refactoring in the 0.3 release cycle, and is effectively
> "unsupported" during the 0.2 release cycle.  Something like your
> structuring may take effect in the 0.3 refactoring, or it may not.
>

ok .. I'll stay with my stuff right now and use it.

> Hm.  This strikes me as problematic to use with CIS bindings, unless the
> pool is a proxy of some kind, and then it needs to also know when to
> allocate/release an object.  My architectural assumption about threads and
> pooling is that you'll create separate instances of the App-level object
> and pool *those*, rather than individual components within the
> application.  This works well in Zope, and it localizes the lifecycle
> issue, while avoiding proxies and pretty much all possible thread
> synchronization.

I think this is to "Zope-Centric". In my opinion, Pooling Data-Access is a 
must but do you really think that Process-Objects (things that implement
mostly logic) should be pooled as whole ??? 

What about sharing data between threads ?? this is one of the most important 
matters for me using threads .. otherwise I could use seperate processes as 
well ..

I think that it will be a major performance problem, if every call from 
outside (e.g. get me this Attributes from that Object out of the LDAP/SQL)
leads to instancing a complete app-instance (even we are using SEF.Service
mostly), creating a new connection, authenticating it, initializing the 
Database and Caches. Using persitent connections and a certain 
pooling-algorithm that can handle the things you talked about above e.g.:

Within my TransactionAwarePool there are 3 Classes:

1. InstancePoolService: Transparently switches between the objects it holds
    for each incoming call and can be used to serve Instances without
    modifying code that works without pooling. it is a Mixture of Once and
    AutoCreateable and therefore it's not too much overhead (depends only on
    the algorithm that is needed to select/manage instances for calls. It 
    does not explicitly depend on threads to switch .. e.g. the implementation
    of it in Transactions uses the TransactionID to determine, if a thread 
    already has a Instance Assigned or not. If not, it try's to return a free
    Instance, if none is avaliable, the call is blocked until an Instance gets
    free again. With this approach I'm able to share Transactions and the 
    Instances between threads that belong together, which is what we wanted 
    to be able to.

2. PooledObjectWrapper: This class is a wrapper for a pooled instances maybe a
    service may be something else. it has two methods: use(client) and free()
    those methods are called, when an Instance is used or not needed anymore.
    It has a ObjectTransactionNotifier.

3. ObjectTransactionNotifier: Similar to your Database.Transactions.\
    TransactionNotifier and it helps the IPS/POW to find the Transaction-
    Boundaries and frees instances with forget(=tpc_finish). Similar Classes
    could recognize Users that use an Instance for the first time and register
    a callback when they logout or just define an idle timeout.

In all "Non-Database-Relevant" parts there are not too much things two worry 
about threads in our cases i think.

do you still think this approach won't work in most cases ??


cheers

Ulrich Eck
net-labs Systemhaus GmbH
ueck at net-labs.de

p.s. sorry for the inconvinience that you have with my postings recently, but 
we have a central mailbox (lists at net-labs.de) that is subscribed to all our 
mailinglists to minimize the amount of traffic on our connection. is it 
possible to allow ueck at net-labs.de to post but without receiving any messages 
??