Ok, we think we have found why our application transaction handling is
not working right, but want to verify it.
We downloaded and setup JPetStore to run against our Oracle database.
No changes where made to the configuration of the database. We modified
the order placing function to force it to violate a primary key
constraint on one (create order) of the multiple sql commands it does
within the transaction. This caused all the commands to rollback as we
would expect. No update of the quantity on hand of the item occured.
In our application we define a DaoManager, but never reference the
SqlMapDaoTemplate. Instead, in our persistance layer, we define using
the SqlMapClientBuilder a SqlMapClient. All operations use this
SqlMapClient (sqlmapclient.queryForList...). Calls to start a
transaction execute daomgr.startTransaction. Extra layers of
inheritance where implemented in the application by the then project
head. Don't ask me why. Anyway, when we do a transaction all the sql
commands up to the command that fails commit, when they should all
rollback. Same database with same configuration on it.
It appears that JPetStore uses the DaoManager to execute the
queryForList and such with no actual build of a SqlMapClient. Am I
correct? Is that why our transactions don't rollback correctly?
Otherwise, I am at a loss for why JPetStore rolls back correctly and our
application does not. We are having to use stored procedures right now
to get the proper rollback, but one of the requirements is that the
application not be database dependant. In other words, no having to
convert stored procedures on one database to another.
Any help or comments would be greatly appreciated.
Al
