-----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.
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. 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 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. 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. - 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.
-Michel
"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
participants (2)
-
Jay, Dylan -
Michel Pelletier