|Subject||Re: [firebird-support] Advice regarding transactions.|
> I seeking opinions regarding FB transactions in an application. My current apps call some complex lookup modules, usually a DLL. When I use the sqls (which are all read only selects) under the application main transaction (which allows for db updates) the lookup modules can take some time. I did experiment with a separate transaction for the lookup modules however some customer sites which use Windows 2003 servers upwards cause the modules to take some time to startup which defeats the purpose of the lookup.Get used to transactions, understand them, understand the different
> What is the correct way to approach this? Is it a matter of multiple transactions specific to the sql tasks (i.e. read only, retain commit)? or should it be one transaction per application?
> You opinions please would be appreciated.
settings, play with them in different smaller test applications. A clear
understanding of Firebird transactions and their usage is IMHO THE
number one golden nugget in developing Firebird-based client
applications. Really! I've seen in various customer workshops, that a
bad transaction management in the client application is one of the most
important affecting issue on server slow down etc ...
Make use of the various transaction settings (isolation level,
read-only/read-write ...) depending on the application requirement.
Read-only transactions do have less overhead than read-write
transactions, thus explicitly use them when you don't need to write
something. In combination with read committed as isolation level, you
won't block moving OIT/OAT forward, even for long running transactions
or running them in some sort of auto commit mode, which basically calls
commit retaining behind the scene.
Again, grep everything on Firebird transactions from the Internet (or
Helen's book ...) and try to understand that. The time is very well
Download LogManager Series, FB TraceManager today!
Continuous Database Monitoring Solutions supporting
Firebird, InterBase, Advantage Database, MS SQL Server