Hi everyone,
Am using D5 with Firebird 1.5 (dialect 3/Linux: Kubuntu). Have been using BDE since the beginning of time and looking for a replacement. I have been evaluating Zeos 661beta for more than a month now and I am glad it seems very promising.
I understand the Zeos build in behaviour is to perform soft commits -at least on firebird-. Soft commits tend to create garbage that need further to be sweeped. Because of this some -like me- would rather use hard commits instead. OK, I already know I can hard commit by closing the connection, but wouldn't it be better if this aspect could be application configurable? I believe certain BDE versions support the distinction between soft/hard commits.
Cheers Stamatis
Just a few thoughts on soft/hard commits
Moderators: gto, cipto_kh, EgonHugeist
-
mdaems
- Zeos Project Manager
- Posts: 2766
- Joined: 20.09.2005, 15:28
- Location: Brussels, Belgium
- Contact:
Hi,
Let's start saying I'm not a Firebird specialist. Is this hard/soft difference about the difference between the isc_commit_retaining and isc_commit_transaction api calls when doing a commit? In that case this could (in my opinion) be programmed like this:
- add 'hard_commit:boolean;' to the private fields declaration of TZInterbase6Connection
- Change TZInterbase6Connection.Create : hard_commit := StrToBoolEx(Info.Values['hard_commit'])
- Change TZInterbase6Connection.Commit and rollback functions : if hard_commit then isc_commit_transaction instead of isc_commit_retaining.
It may be necessary to call StartTransaction again after committing and rolling back when working with the 'hard' versions. Not sure about that when reading Interbase API documentation.
This solution does not allow to change this behaviour while a connection is open. To implement that we would have to add a property which is very database specific to the connection component. We really don't like to do that.
@scasparz : do you think you could try this? Is it what you needed?
Mark
Let's start saying I'm not a Firebird specialist. Is this hard/soft difference about the difference between the isc_commit_retaining and isc_commit_transaction api calls when doing a commit? In that case this could (in my opinion) be programmed like this:
- add 'hard_commit:boolean;' to the private fields declaration of TZInterbase6Connection
- Change TZInterbase6Connection.Create : hard_commit := StrToBoolEx(Info.Values['hard_commit'])
- Change TZInterbase6Connection.Commit and rollback functions : if hard_commit then isc_commit_transaction instead of isc_commit_retaining.
It may be necessary to call StartTransaction again after committing and rolling back when working with the 'hard' versions. Not sure about that when reading Interbase API documentation.
This solution does not allow to change this behaviour while a connection is open. To implement that we would have to add a property which is very database specific to the connection component. We really don't like to do that.
@scasparz : do you think you could try this? Is it what you needed?
Mark
Hi again,
Although I have programmed a lot on Interbase/Firebird sadly this has not been over their respective APIs. I too have studied the ZEOS code, and like Mark I though this could be as easy as that. I did modify the ZEOS source in such a manner that depending on the value of a ZDbcInterbase6 (unit) declared boolean constant, the tzConnection.Commit method was switching calls to either the isc_commit_retaining or the isc_commit_transaction procedures (both located at the ZPlainFirebirdDriver unit).
Well it did not work. If I am not wrong this is due to the way the tzConnection.StartTransaction is materialized. Seems that starting a transaction which will be soft committed is much different from starting a transaction which will be hard committed instead, from the FB's API point of view. Again if I am not wrong ZEOS attempts to open a -to be hard committed transaction- immediately after connecting. When disconnecting the isc_commit_transaction (hard commit) procedure is been called.
So unless someone more knowledgable than me will be kind enough to inform me that I am trying something stupid, I intend to further study the ZEOS source, around the ways that an FB transaction is actually initiated. The idea is to apply the same switch while beginning a transaction.
Whether this could work or not I do not know. I 'll stay in touch.
Cheers
Stamatis
Although I have programmed a lot on Interbase/Firebird sadly this has not been over their respective APIs. I too have studied the ZEOS code, and like Mark I though this could be as easy as that. I did modify the ZEOS source in such a manner that depending on the value of a ZDbcInterbase6 (unit) declared boolean constant, the tzConnection.Commit method was switching calls to either the isc_commit_retaining or the isc_commit_transaction procedures (both located at the ZPlainFirebirdDriver unit).
Well it did not work. If I am not wrong this is due to the way the tzConnection.StartTransaction is materialized. Seems that starting a transaction which will be soft committed is much different from starting a transaction which will be hard committed instead, from the FB's API point of view. Again if I am not wrong ZEOS attempts to open a -to be hard committed transaction- immediately after connecting. When disconnecting the isc_commit_transaction (hard commit) procedure is been called.
So unless someone more knowledgable than me will be kind enough to inform me that I am trying something stupid, I intend to further study the ZEOS source, around the ways that an FB transaction is actually initiated. The idea is to apply the same switch while beginning a transaction.
Whether this could work or not I do not know. I 'll stay in touch.
Cheers
Stamatis
I dig a little into sources and found:
1. TZConnection.StartTransaction method doesnt call driver's StartTransaction. It seems that other supported ZeosLib RDBMS doesn'n need explicit start transaction after commit as Interbase / Firebird needs when hard commit occurs.
2. TZInterbase6Connection.Open is the only place where StartTransaction is called (for IB/FB). Since soft commit doesn't really ends transaction, current driver implementation doesnt starts new one.
I think this should be addressed trying not to affect already working code but this could lead to some hacking in TZConnection in commit code:
1. If isn't interbase nor firebird behave as is now then exit (if FConnection is...).
2. Count opened datasets.
3. If there is no opened dataset, call HarCommit() instead of soft Commit() (casting...).
And in the driver:
1. Create HardCommit() method.
2. Create a boolean flag: InTrans.
3. Soft commit doesnt end transaction, there is nothing to change on Commit().
4. HardCommit() ends transaction, then InTrans := false;
5. Before any CreatePreparedXXXX (I'm not shure if is there, I just spend few minutes browsing Zeos's source) if not in transaction (because hard commit) start one.
TO INTERBASE / FIREBIRD MAINTAINER:
Do you agree with my suggestion?
Can I help you?
I'm interested on this since I'm thinling on using lazarus intead of Delphi for a new product for my company and this product must support various RDBMS, Firebird is one of them.
What wonders me now is how many people is using Zeos with Interbase and/or Firebird.
Regards.
1. TZConnection.StartTransaction method doesnt call driver's StartTransaction. It seems that other supported ZeosLib RDBMS doesn'n need explicit start transaction after commit as Interbase / Firebird needs when hard commit occurs.
2. TZInterbase6Connection.Open is the only place where StartTransaction is called (for IB/FB). Since soft commit doesn't really ends transaction, current driver implementation doesnt starts new one.
I think this should be addressed trying not to affect already working code but this could lead to some hacking in TZConnection in commit code:
1. If isn't interbase nor firebird behave as is now then exit (if FConnection is...).
2. Count opened datasets.
3. If there is no opened dataset, call HarCommit() instead of soft Commit() (casting...).
And in the driver:
1. Create HardCommit() method.
2. Create a boolean flag: InTrans.
3. Soft commit doesnt end transaction, there is nothing to change on Commit().
4. HardCommit() ends transaction, then InTrans := false;
5. Before any CreatePreparedXXXX (I'm not shure if is there, I just spend few minutes browsing Zeos's source) if not in transaction (because hard commit) start one.
TO INTERBASE / FIREBIRD MAINTAINER:
Do you agree with my suggestion?
Can I help you?
I'm interested on this since I'm thinling on using lazarus intead of Delphi for a new product for my company and this product must support various RDBMS, Firebird is one of them.
What wonders me now is how many people is using Zeos with Interbase and/or Firebird.
Regards.
I'm using Zeos with FB 
I also already ask about this topic and you also can look in http://zeos.firmos.at/viewtopic.php?t=110
There is some question:
1. Maybe you can show me which FB/IB article that said after hard commit it must be followed by start transaction?
You can get the latest SVN from Mark (mdaems) because the snapshot in http://zeosdownloads.firmos.at/downloads/snapshots/ is still Rev294
Please make change and submit in ZeosBug (http://zeosbugs.firmos.at/login_page.php) or maybe in other place Mark?
Feel free to contribute
I also already ask about this topic and you also can look in http://zeos.firmos.at/viewtopic.php?t=110
There is some question:
1. Maybe you can show me which FB/IB article that said after hard commit it must be followed by start transaction?
You can get the latest SVN from Mark (mdaems) because the snapshot in http://zeosdownloads.firmos.at/downloads/snapshots/ is still Rev294
Please make change and submit in ZeosBug (http://zeosbugs.firmos.at/login_page.php) or maybe in other place Mark?
Feel free to contribute
-
mdaems
- Zeos Project Manager
- Posts: 2766
- Joined: 20.09.2005, 15:28
- Location: Brussels, Belgium
- Contact:
If its a bug (ie. an implemented but malfunctioning feature) it should be logged in the bugtracker and patches/samples can be added.
If it's a new feature that's not available yet, please add patches to the 'user patches' or 'user contributions' forums.
If you don't want to do the coding yourself, but merely ask to implement a new feature, or if you want to discuss a new feature implementation please use the 'Feature Requests' forum.
Please start coding from SVN testing branch. The available snapshots should be 'fresh' enough to work with. Of course, real SVN is better if your connection allows it.
Mark
If it's a new feature that's not available yet, please add patches to the 'user patches' or 'user contributions' forums.
If you don't want to do the coding yourself, but merely ask to implement a new feature, or if you want to discuss a new feature implementation please use the 'Feature Requests' forum.
Please start coding from SVN testing branch. The available snapshots should be 'fresh' enough to work with. Of course, real SVN is better if your connection allows it.
Mark
Just a question for ssamayoa
Hi guys,
i have done my studying and as ssamayoa found, zeoslib starts a new transaction every time a zconnection is opened on fb. Also zeoslib does an implicit hard commit just before closing the connection.
I have been doing disconnecting/connecting as a means for a hard commit for some time now, and I admit I was not having any issues. Performancewise, closing and opening the connection does not seem to be slow (still using D5 on fb1.5 located on Kubuntu 6.10).
ssamayoa I would really be very interested to understand what is that makes you say that "Disconnect / connect is a very expensive method for hard commit to occur"?
cheers
Stamatis
i have done my studying and as ssamayoa found, zeoslib starts a new transaction every time a zconnection is opened on fb. Also zeoslib does an implicit hard commit just before closing the connection.
I have been doing disconnecting/connecting as a means for a hard commit for some time now, and I admit I was not having any issues. Performancewise, closing and opening the connection does not seem to be slow (still using D5 on fb1.5 located on Kubuntu 6.10).
ssamayoa I would really be very interested to understand what is that makes you say that "Disconnect / connect is a very expensive method for hard commit to occur"?
cheers
Stamatis
Re: Just a question for ssamayoa
At current LAN speed (10/100Mbps) and with the current server speed there is no much impact on connect/discobbet and only older IB/FB versions suffer from this problem with such network speed. But if you connect using slow connections (Less than 1Mpbs let say 256Mbit) you will see what I mean.scasparz wrote:Hi guys,
ssamayoa I would really be very interested to understand what is that makes you say that "Disconnect / connect is a very expensive method for hard commit to occur"?
On the other hand such way of hard commit, in my point of view, is a work arround and this behaviour of Zeus is in the gray zone between bug and feature.
Regards.
-
mdaems
- Zeos Project Manager
- Posts: 2766
- Joined: 20.09.2005, 15:28
- Location: Brussels, Belgium
- Contact:
I understand that...
Could it be an option for the people who want to write their code to be used with hard commits? I don't know the zeoslib implementation of Firebird very well (actually I know very little about firebird), but does it use cursors that should stay open?
Would a hard commit be possible when the user closes all TZQuery components first? I can't imagine anything that should stay open apart from the connection in such a situation. I agree... that requires the user to close the datasets himself... Maybe we could cause the Commit to fail with the 'use_hard_commit' option set and cursors being open?
Mark
Could it be an option for the people who want to write their code to be used with hard commits? I don't know the zeoslib implementation of Firebird very well (actually I know very little about firebird), but does it use cursors that should stay open?
Would a hard commit be possible when the user closes all TZQuery components first? I can't imagine anything that should stay open apart from the connection in such a situation. I agree... that requires the user to close the datasets himself... Maybe we could cause the Commit to fail with the 'use_hard_commit' option set and cursors being open?
Mark
Re: Just a question for ssamayoa
Hi everyone,
Yes, ssamayoa, I understand what you are saying, and I think you are most probably right. My work is on LANs hence it is not much of a problem for me.
Ideally zeos should have some sort of a property regarding the kind of transactions. I hope to see something like this in the next version whenever it comes out.
I am still very fond of zeos. There are issues, for instance when calling a stored procedure, one should declare the output parameters before the input ones, or some issues with the devexpress grid (when it contains currency lookup fields with the edgoLoadAllRecords property on), but all and all zeos seems to be a very decent job. In fact now that I am thinking of it, this clearly demonstrates how difficult is to produce such a wide (it supports so many different databases) software in a bug free manner.
Keep the good work dudes.
cheers
Stamatis
Yes, ssamayoa, I understand what you are saying, and I think you are most probably right. My work is on LANs hence it is not much of a problem for me.
Ideally zeos should have some sort of a property regarding the kind of transactions. I hope to see something like this in the next version whenever it comes out.
I am still very fond of zeos. There are issues, for instance when calling a stored procedure, one should declare the output parameters before the input ones, or some issues with the devexpress grid (when it contains currency lookup fields with the edgoLoadAllRecords property on), but all and all zeos seems to be a very decent job. In fact now that I am thinking of it, this clearly demonstrates how difficult is to produce such a wide (it supports so many different databases) software in a bug free manner.
Keep the good work dudes.
cheers
Stamatis