Eric,
If you can tell us "why" you are doing what you are doing perhaps we
can assist you in providing some suggestions on how it can be
accomplished.
Brandon
On 6/9/06, Clinton Begin <[EMAIL PROTECTED]> wrote:
Fortunately the answer is simple, unfortunately you're probably not going to
like it. :-)
NEVER cross thread boundaries within (what you expect to be) a single
transaction. Never.
Cheers,
Clinton
On 6/5/06, Eric T. Blue <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I want to find out the easiest possible way to start a transaction, create
a thread that performs DAO inserts, and still have the newly created thread
honor the start and end transaction from the launching application.
>
> I'm working on a project where I'm using iBatis DAO with SQLMAP as my
transaction manager. Up until this point transactions and rollbacks work
fine.
>
> daoManager.startTransaction();
>
> try {
> service.createObject (a);
>
> daoManager.commitTransaction();
>
> } catch (ServiceException e) {
> // Handle exception
> } finally {
>
> daoManager.endTransaction();
> }
>
> I now have a situation where instead of calling service.createObject()
directly I'm creating an encapsulated unit of work and running with a new
thread. What I've discovered is that whenever an exception is thrown, the
create Object exists in the database, although commitTransaction has never
been called. After browsing through the mailing list, and eventually the
code, I discovered that the dao manager (DaoContext) is using ThreadLocal to
keep track of transaction and state. Given this fact, is it even possible
to solve my problem without having to change the underlying code or right
some sort of wrapper class.
>
> What I'm a little confused about is that default autocommit is set to
false. If the launched thread performs the INSERT, even though it is
unaware that start transaction and end transaction are happening, why is the
record being committed? Any help would be appreciated.
>
