[Zope] sub-transaction in DTML?

[Jay, Dylan]

> -----Original Message-----
> From: Michel Pelletier [mailto:michel@digicool.com]
> 
> "Jay, Dylan" wrote:
> > 
> > > -----Original Message-----
> > > From: Michel Pelletier [mailto:michel@digicool.com]

> > 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 suspected this might be the case.

> > 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?

Havn't been able to so far. It seems you have to have a reasonably complete
sybase installation for the DA to work.
  
> > - 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

That is a possible option. Does anyone know what the issues with this are?
From memory I think the non-thread-safeness of the odbc drivers themselves
was not the only problem. I suspect the python odbc interface might have
been not thread safe also. Can anyone confirm this?