We have a multithreaded app written in Clarion 9 (win32), running on several
win 2012 64 bits r2, connecting to Firebird 3 (latest build) via ODBC 32
bits (latest ODBC). We are experiencing a rare propblem, that happens not
very often. The issue is as follows:
The application does not use "begin transaction and commit", so we let the
database commit automatically
after a write process, we read the table from another thread inside the app
or from another app inside the same OS session, and the data is not there.
Of course after a few seconds (or milliseconds) the data is available. Our
concern is that we have a sequence of code that assume whatever was written
5 lines above is already available for reading, but it is failing every so
often. One solution we are considering is to use "explicit" begin
transaction and commit instead of implicit, any thoughts? (in the past, when
firebird was on version 1.5 or 2) we tried to use explicit transactions and
the system would lock up every 20 minutes... probably deadly embrace, but we
believe it was not related to the application itself, we attributed at the
time to a possible bug somewhere betweeen the ODBC or the Firebird engine
because the same app running against another DB engine would not lock up.
Any suggestions?
Cheers,
Fabian
Posted by: <fabianch@itbizolutions.com.au>
| Reply via web post | • | Reply to sender | • | Reply to group | • | Start a New Topic | • | Messages in this topic (1) |
Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu. Try FAQ and other links from the left-side menu there.
Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
No comments:
Post a Comment