Uwe Grauer wrote: > Paul McNett wrote: >> Uwe Grauer wrote: >> What I think your objection boils down to is not enough control, from >> your application code, as to when the transactions BEGIN, COMMIT, and >> ROLLBACK. So you aren't able to get atomicity on all the database >> actions that you'd like (in the classic bank debit example, one account >> is getting debited and that transaction committed, instead of having >> both accounts credited/debited and then committing that transaction). >> >> Am I close? >> > > Yes, that's the point. > >>> There are the following cases: >>> 1. your database doesn't support transactions. >> I believe every database we currently support supports transactions. >> Indeed, I believe every database we currently support is ACID compliant. >> However, that may or may not be the case in the future, when/if we start >> supporting VFP or JET databases, and the like. >> > > MySQL with a ISAM backend doesn't support transactions.
True; I'd forgotten about that. >>> 2. your database supports autocommit and supports transactions. >>> 3. your database only supports transactions. >>> 4. your database doesn't have autocommit but you have to do a commit >>> in order to mimic a autocommit in the framework. >> How does 4 differ from 3? >> > > 4 is what dabo does with the current implementation for firebird. > Firebird doesn't have what other databases do when they use autocommit. > What firebird does have is commit retaining, which is close to > autocommit. The problem with this is, that firebird has a MGA > architecture. With commit retaining firebird has to manage a chain > of all open connctions which are doing a commit retaining. That isn't > what you want to use in a high concurrent environment. > >>> Currently i can't use ACID features in firebird. >>> That's why it is something i want to get working for a long time now. >> Is this because the framework is saving your data automatically at >> inappropriate times, or something else? >> > > Yes, Dabo does a commit after a insert/update statement. > Logically this is like a autocommit (4). What happens when you set AutoCommit=False for firebird and manage the commits yourself? >>> >From the "help" i got by asking questions on this i have assumed that >>> the dabo users don't know much about transactions or that until now >>> nobody really thought about it. >> I think we've spent a lot of time trying to help you, but none of us >> have a lot of time to get to the bottom of the problems you've had, as >> they seem to be firebird-specific and we don't seem to be having >> problems with transactions in MySQL, SQLite, and PostgreSQL. >> > > I was willing to do the necessary adjustments for firebird, but couldn't > get the right answers for my questions. > See dabo-dev thread "Transaction handling in dabo". Ok, I began to review that thread, and found as the most recent message from Ed: """ On Mar 12, 2007, at 10:50 AM, Uwe Grauer wrote: > Now i'm asking again: > How should we make explicit transactions behave like it > has to be and still have the current behavior to mimic a > autocommit setting? OK, I get it. I will do it myself. When it is posted, please test and let me know if it works. """ Did nothing come of this? If not, why don't you add a ticket with the relevant info so we don't forget about it as we go forward. >>> If this is not the case we should try to work out a better way to handle >>> those issues. >>> where the docs should be improved. >> I agree, and would welcome better docs and ideas on how to better handle >> transactions, or at least to test how they are currently working. But as >> I said above, I am not having any problems with transactions, in my >> SQLite app at least. I have bizobjs about 5 levels deep, with >> new/deleted/edited records in any or all levels, and multiple bizobjs at >> each level, and when I save the parent bizobj all the resulting SQL ends >> up in a single transaction. If a db exception occurs, everything is >> rolled back for me. So, it seems to be working but admittedly I'd love >> to see a test suite making sure that it works correctly in all >> conceivable cases. >> > > This is not the case for firebird, and i think it is not the case for > some other backends too. > I added begin/commit/rollback logging to the DatabaseActivityLog to > be able to see what dabo is doing for firebird. > Maybe we should add this for other databases also and write testcases to > be sure about if it works as it should. If we could come up with a set of DDL that basically works on all databases, we could write a test script that turns on the db activity log, runs the DDL to create the tables, and then does SQL queries using bizobjs. Then, we could diff the db activity logs to see if all backends are doing the same things in the same order. -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/dabo-dev/[EMAIL PROTECTED]
