[Zope] sub-transaction in DTML?

[Michel Pelletier]

"Jay, Dylan" wrote:
> 
> > -----Original Message-----
> > From: Michel Pelletier [mailto:michel@digicool.com]
> > Sent: Wednesday, March 15, 2000 4:19 AM
> > To: Jay, Dylan
> > Cc: 'zope@zope.org'
> > Subject: Re: [Zope] sub-transaction in DTML?
> >
> > "Jay, Dylan" wrote:
> > >
> > > I have a method that takes a long time on a system that
> > uses a level 2 DA,
> > > therefore it blocks the entire site
> >
> > To be more specific, it blocks all other requests through
> > that and other
> > level 2 DAs.  Non SQL related calls and level 3 DA calls will not get
> > blocked.
> >
> > > (it also uses UserDB so everything uses
> > > the DB).
> >
> > Yeah that kinda puts a damper on the whole site... but that's just
> > because every access is now an SQL related call.
> 
> but having a DB manage my user data is not an unresonable requirement on a
> site.

Your right, and Zope does satisfy that requirment.
 
> > > How can I put sub-transactions in my DTML to give others a chance
> > > to use the site?
> >
> > This is not what ZODB sub-transactions do.  Even if you were using a
> > relational database that has a notion of sub-transactions (Oracle has
> 
> why do I need a concept of a sub-transaction.

You don't.  But that's what you were asking so that's what I was
answering.

> Is there just something that I
> can call that will commit all changes up until a certain point and then
> begin the new transaction?

I don't think the problem is that a transaction needs to be commited,
the problem is that the DA is engineered to block until it completes the
task at hand.  Even if you did call get_transaction().commit() from
python or an external method or whatever, I don't think it would unblock
your call.  You can try it, of course.

> I realize this will break the transaction model
> to some extent but if the method is long and each iteration is indepedent
> this seems a reasonable thing to do.
> 
> > 'nested transactions' for example) that would not stop the
> > blocking (of
> > course if you were using Oracle you would be using a level 3 DA...).
> > ZODB sub-transactions allow changed objects to get flushed to a temp
> > filestorage so that you can accumulate more object changes
> > then can fit
> > in virtual memory.  There is no mapping of sub-transaction
> > semantics to
> > any of the DAs.  In fact, if I remember correctly using ZODB
> > sub-transactions with SQL methods is Not A Good Thing.  I
> > don't remember
> > the exact details.
> >
> > Solutions?  Execute a shorter query or upgrade to a concurrent DA.
> 
> To do the work using a shorter query would mean breaking the method up into
> chunks and then having to call it multiple times which is pretty ugly.

Yes it is.
 
> Tell me how to get a concurrent DA on NT without breaking the bank and I'll
> do it.
> So far I have:
> 
> - MS SQL server - Apparently sybaseDA will work but havn't been able to
> compile it on NT. You need certain files from sybase I believe.
> 
> - SQLAnywhere - same problem as above.

Can you not get your hands on the Sybase client libraries?
 
> - Oracle - too expensive.
> 
> - MySQL - No transactions.
> 
> - PostgresSQL - Got the NT binaries but can't get it working. Also can't
> compile the postgresDA.
>
> - ODBC - Not level 3.
> 
> As far as I can tell the above represents all the options I have open to me.

I don't know if we have immediate plans to bring the ODBC DA up to level
3.  Probably not any time soon unless it is a customer requirement.

Another option is to threadsafe the ODBC DA yourself.

http://www.zope.org/Members/petrilli/WritingADA

-Michel