> -----Original Message----- > From: Karr, David > Sent: Tuesday, December 19, 2006 11:23 AM > To: Jakarta Commons Users List > Subject: [jelly] What happens if sql:update isn't wrapped > with a sql:transaction element? > > I have a large dbinit script written in Jelly. I ended up > having my "insert" tag have a sql:update tag inside of a > sql:transaction tag. > This works, but my script is quite large, and I'm wondering > about ways to optimize it. > > I imagine I could restructure the entire script so that a > single "sql:transaction" tag wraps everything, and my > "insert" tag doesn't use update inside an additional > transaction. I imagine that would work, but it would make > for a heck of a large transaction.
After I wrote this, I tried doing this (it wasn't hard to do). Unfortunately, it failed when I ran it. For some reason, the "sql:update" complained about a null dataSource property. In my main script, I do an "import" of a "dbutils.xml" that I wrote which defines a "dbutils" taglib. In dbutils.xml, I have an "insert" tag that wraps a sql:update inside a sql:transaction, where the dataSource is provided in the sql:transaction. The value of the dataSource is provided by a variable set by a "sql:setDataSource" tag in the main script. This works fine. So, what I tried to do was write a "insertnots" tag, removing the wrapping sql:connection tag, and then placing that sql:connection tag in my main script, wrapping all of my "insert" tags (with an end tag at the end of all of them). I then changed all the "insert" tags to "insertnots". When I ran this, it complained in the sql:update about the dataSource being null. Is there some reason there would be difference in where the sql:connection was wrapping the sql:update? > > What would happen if I simply removed the wrapping "sql:transaction" > element and added the datasource attribute to the sql:update call? > Would that result in effectively the same thing, making each > statement autocommit? This isn't what I want, I just want to > understand what this would do. > > My back end is Oracle, if that matters. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
