Paul McNett wrote: > Uwe Grauer wrote: >> Paul McNett wrote: >>> Uwe Grauer wrote: >>>> Would someone please answer the questions about the meaning >>>> of autocommit? >>>> See: http://svn.dabodev.com/trac/dabo/wiki/TransactionHandlingIdeas >>>> This is a outstanding issue for a long time now. >>> The doc says: >>> >>> """ >>> AutoCommit >>> >>> Do we need explicit begin/commit/rollback commands for transactions? (bool) >>> """ >>> >>> I believe that the original intent of AutoCommit was a flag to let >>> methods in dCursorMixin know whether dCursorMixin has to explicitly >>> commit transactions for a given backend or not. >>> >>> If that is true, I don't believe AutoCommit should have ever been >>> exposed to the application developer, as it is an internal >>> implementation detail. >>> >>> However, I also believe you can set AutoCommit for some backends, which >>> will change the behavior of the backend. Some backends autocommit by >>> default, most not, and some if not all allow the user to change the >>> behavior. >>> >>> But looking at the code, it also looks like setting AutoCommit can >>> silently fail for some backends, so we should raise an exception there I >>> think. >>> >>> If nothing else, we certainly need to rewrite the docstring to state >>> more explicitly what the property does, and how the initial setting of >>> the property is derived. >>> >>> Ed, what do you think? >>> >> Well, there is more than one interpretation of this. >> If you look at it from a standpoint of a developer who doesn't >> know much about transactions, then it's true that it is just a >> implementation detail. But if you as a developer want to use ACID >> in your database, the question is much more than this. > > Let's back up a bit and remember that ACID compliance is a > database-level concept, not an application-level concept. Either your > database is ACID-compliant, or it isn't. No wrapper around that > database, such as kinterbasdb or dabo can change whether or not the > database is ACID compliant. > > 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. > >> 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). > >> >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". > >> 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. Uwe _______________________________________________ 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]
