I’m implementing
storeRow method in my statement delegates (see
FreeformStatementDelegate ) in order to write data (inserting and/or updating) to database. So far I (almost) have my “semi-automated” query constructor, but in the process of debugging I’ve encountered this error that slows my development process. I’m using a
FieldGroup to bind some data to a Grid datasource. I do a
setBuffered() when setting it and a
FieldGroup.commit() for commiting the modified data to the data source and, finally, a d
ataSource.commit() , being this data source an
SQLContainer . Please feel free to correct me if this is not the right approach but this is what I’ve deduced so far.
Well, by commiting the dataSource the delegated method should write to the database, and that seems to be (almost) fine, since I see the proper methods are fired an so on. But if I stop execution because I found a bug during a trace or so, in successive executions often this error appears. It’s being fired around line 58 in AbstractTransactionalQuery.java, in method
beginTransaction() . There it checks for an existing transaction and, if it exists, or more properly, if is “in” a transaction, this "
A transaction is already active! "
IllegalStateException is thrown. At the beginning I had to stop the application and start it again in order to pass this point; now it’s starting to be more recurrent and it’s preventing execution when reaching this point.
I already added a
Catch for that exception and I’m doing a
dataSource.rollback() in that case, but that seems to do nothing. So by now I’m not that sure if it’s being due to my errors or is something more related to exhausting the connection pool or whatever.
It’s been tree weeks and I didn’t get any reply. Well, the initial problem which led to the thread title question was almost solved, and I’m able to do INSERTs, but I still get “A transaction is already active!” errors here and there when I do an
SQLContainer.commit() and there happen to be errors in the process and I try to “recycle” the operation. To put you in context: I am on a form window and by trying to “recycle the operation” I mean “to click the insert button again without closing the window, losing the form data and having to restart my app and enter the info again”. How can I manually “end and already active” transaction if, for whatever reason, it failed, to be able to do minor changes in the code and partially compile them without having to start a new full compile?
SQLContainer.rollback() seems to do nothing in this case, and it’s very annoying.
Shouldn’t SQLContainer end a transaction after performing a
rollback() ?
I’m still continuosly facing the “A transaction is already active!” in successive attempts to save a record to an SQLContainer after having failed the first time due to any kind of errors. Although I manually do in an
SQLContainer.rollback() in my
catch clause, the transaction remains active and I have no way of getting rid of it until I restart my app.
If it’s not done automatically when performing the
rollback() , then maybe I should have a method to do it manually. Unfortunately, that’s done in the
QueryDelegate property of SQLContainer, which has it declared as private. Also, SQLContainer has a protected
getQueryDelegate() method, so it is of no use either.