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