Brandon Goodin wrote:
Actually JPetstore does use the SqlMapDaoTemplate. All of the DAO
class extend BaseSqlMapDao which extends SqlMapDaoTemplate.
In your case I am not completely clear on what you are doing. Perhaps
you can provide code from your application that shows us how you are
using iBatis. Code coupled with you explanation can go a long way.
Brandon
public class BaseSqlMapDao extends SqlMapDaoTemplate {
On 2/10/06, Albert L. Sapp <[EMAIL PROTECTED]> wrote:
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
Brandon,
I will try this again and leave out as much of the exception handling as
I can. I will try to trace through what I think is happening though I
have never fully understood the explaination I was given.
1. Say we want to create a inventory item. We have collected all the
information in our web page and created a transfer object bean in our
action. The action calls the appropriate manager. In this case, it
calls the StoreroomManager, which is implemented in the
StoreroomManagerImpl and extends the BaseManager.
2. We execute "startTransaction();", which executes
"daoManager.startTransaction();" in the BaseManager. BaseManager is
where the DaoManager is defined and configured.
3. Then, we execute "inventoryItemDAO.create(newInventoryItem);".
inventoryItemDAO was defined "inventoryItemDAO =
(InventoryItemDAO)getDao(InventoryItemDAO.class);" using the getDao
defined in BaseManager.
4. We go to SqlMapInventoryItemDAO which extends BaseDAO.
5. The BaseDAO executes these commands:
a, "reader = Resources.getResourceAsReader(sqlMapConf);"
b. "sqlMap = SqlMapClientBuilder.buildSqlMapClient(reader);"
c. create() contains "executeUpdate(getEntityName() + "Insert",to""
which translates as "executeUpdate("InventoryItemInsert", inventoryItem)"
d. executeUpdate contains "return
sqlMap.update(InventoryItemInsert, inventoryItem);"
6. This executes the statement in the inventoryItem.xml file called
"InventoryItemInsert".
7. If no exceptions are thrown, we execute "commitTransaction();",
which executes "daoManager.commitTransaction();" in the BaseManager.
I can send you the files themselves if you need to see them. For single
sql commands in a transaction, it either commits or rollback as we would
expect. With something like:
startTransaction();
invoiceDAO.createInvoice(new Invoice);
for (int i = 0; i < invoiceItem.size(); i++)
{
invoiceItem = (InvoiceItem) invoiceItems.get(i);
invoiceItemDAO.createInvoiceItem(invoiceItem);
}
inventoryItem.updateInventoryItem(inventoryItem);
for (int z = 0; z < transactions.size(); z++)
{
transaction = (Transaction) transactions.get(z);
transactionDAO.createTransaction(transaction);
}
stopTransaction();
Everything is commited prior to an exception being encountered with only
the current sql command, that caused the exception, being rolled back.
Since this is contained in try blocks to trap exceptions, we always call
endTransaction().
In JPetStore, if I remember right, commands are executed through a
daomanager.update() versus a sqlmap.update(). Am I correct? Am I miss
reading JPetStore code execution? By executing the SqlMapClientBuilder
instead of letting the daomanager use the SqlMapDaoTemplate taking
control away from the daomanager transaction control?
If you need the files, let me know. In the meantime, I have begun
rewriting the application in the pattern that JPetstore uses, since I
know that it does the rollback correctly.
Thanks,
Al
