Sub Process_Globals
Private pool As ConnectionPool
Private Tm As Timer
End Sub
Sub AppStart (Args() As String)
pool.Initialize(....)
Tm.Initialize("TM",3000)
Tm.Enabled = True
Try
StartMessageLoop
Catch
Log("main error")
End Try
End Sub
Sub TM_Tick
Private RS As ResultSet
Private Qry,ExecQ As SQL
Tm.Enabled = False
Log("==========================================")
Try
Qry = pool.GetConnection
RS = Qry.ExecQuery("SELECT * FROM table where id = -9")
ExecQ.BeginTransaction
do while RS.NextRow
'do some operations
loop
RS.Close
Qry.Close
ExecQ.TransactionSuccessful
Catch
Log("unable to connect!")
End Try
Tm.Enabled = True
End Sub
When datatabase connection errors happen, Query, ResultSet & Transaction will not closed properly, how to handle it? Or B4J automatically delete unclosed Query,ResultSet & Transaction when next execution occurred? What happen to unfinished transaction? Will it rollback automatically?
Sub TM_Tick
Private RS As ResultSet
Private Qry As SQL
Tm.Enabled = False
Log("==========================================")
Try
Qry = pool.GetConnection
RS = Qry.ExecQuery("SELECT * FROM table where id = -9") ' just a select - nothing to rollback here...
Qry.BeginTransaction
do while RS.NextRow
'do some operations
loop
Qry.TransactionSuccessful
RS.Close
Qry.Close
Catch
RS.Close ' close if open
Qry.RollBack ' only if performing edits or inserts in (do some operations...)
Qry.Close ' close if open so you don't run out of pool handles...
Log("unable to connect!")
End Try
Tm.Enabled = True
End Sub
Those codes under Catch will raised errors when connection to the database is broken.
I can add try... Catch when try to close resultset or query, this way errors will still be cache by sub TM_tick, but the problems still exists, resultset/queries are unclosed, transactions still not finished.
Will these conditions OK or can raise problems to the database?
@incendio as you are working with a transactional database in a transactional manner until the end of the transcation is received by the database (Qry.TransactionSuccessful does exactly this) the real data from you tabels is not altered. So if your connection with the database is broken before the finished command is received you can rest assured that your data will not be altered.
Bruce Dickenson - You know, it really sounds great- but I could have used a little more cow bell...
B4X:
Sub TM_Tick
Private RS As ResultSet
Private Qry As SQL
Tm.Enabled = False
Log("==========================================")
Try
Try
Qry = pool.GetConnection
Catch
' ..... no pool?
Return
End Try
Try
RS = Qry.ExecQuery("SELECT * FROM table where id = -9") ' just a select - nothing to rollback here...
Catch
' .... cant get RS?
Return
End Try
' no return - carry on safely.... You Get The Idea....
Qry.BeginTransaction
do while RS.NextRow
'If you can break something here - Try, Catch....
loop
Qry.TransactionSuccessful
RS.Close
Qry.Close
Catch
RS.Close ' close if open
Qry.RollBack ' only if performing edits or inserts in (do some operations...)
Qry.Close ' close if open so you don't run out of pool handles...
Log("unable to connect!")
End Try
Tm.Enabled = True
End Sub
@incendio as you are working with a transactional database in a transactional manner until the end of the transcation is received by the database (Qry.TransactionSuccessful does exactly this) the real data from you tabels is not altered. So if your connection with the database is broken before the finished command is received you can rest assured that your data will not be altered.
If your db conncetion breakes it will throw an error so you need to catch it within a try catch ... and if those apps will handle huge and critical data like you say you should prepare some tests so you can find out how to handle this exceptions.
Regarding the hanging transactions, results sets or querys i can see in your code that those variables are local to the sub so when the sub finishes those variables will get picked up by the garbage collector, but you need to handle exceptions because you will be using, more likely variables/parameters in your query so if you have a bad query it will also throw an exception so again you need to catch it, analyse it and create your desired outcome. (A little example: if you have an error in an select query you will not get a result set that you need to close ...)
If your db conncetion breakes it will throw an error so you need to catch it within a try catch ... and if those apps will handle huge and critical data like you say you should prepare some tests so you can find out how to handle this exceptions.
Regarding the hanging transactions, results sets or querys i can see in your code that those variables are local to the sub so when the sub finishes those variables will get picked up by the garbage collector, but you need to handle exceptions because you will be using, more likely variables/parameters in your query so if you have a bad query it will also throw an exception so again you need to catch it, analyse it and create your desired outcome. (A little example: if you have an error in an select query you will not get a result set that you need to close ...)
I have handle others exception but no sure for transactions, resultsets/queries. So, since these variables will be handle by garbage collector, I won't need to handle those again.
I am testing RAM consumption right now. This app will runs in loops for 7/24, at it seems RAM consumption is increased every second, will see when it will stop.
Depends on the type of app and on Application_Error code.
Don't put sql.Close inside the same Try / Catch block as it will not be useful. You can either add another layer of Try / Catch or catch the potential exception in the calling code.