WebSphere 5 Data Source UOW warning on new thread

by spawning a thread, it's possible that you're going outside the normal transaction boundaries setup by the container.  You could try creating a global transaction manually and passing it to your Runnable.  It's also possible that those to methods are set to "requires transaction" ... perhaps you could set them to "supports".

Would you be able to give me a sample of how I could create a gloal transaction and pass it to Runnable?  Also, could you tell me where the requires v. supports would be set?

Let's see ...

If I have a runnable like so

class MyThreadRunner implements runnable{  ....

and I have a constructor like this

public MyThreadRunner(javax.transaction.UserTransaction trans)


then in my calling code I can do this:

                  Hashtable parms = new Hashtable();
                  parms.put(
                        Context.INITIAL_CONTEXT_FACTORY,
                        "com.ibm.websphere.naming.WsnInitialContextFactory");
                  InitialContext ctx = new InitialContext(parms);

                  // Perform a naming service lookup to get the User Transaction.
                  ut = (UserTransaction) ctx.lookup("java:comp/UserTransaction");

then instantiate my runnable ...

Runnable r = new MyThreadRunner(ut);

then in my run() method I can call ut.begin() at the start and the ut.commit() or ut.rollback() if there's an error.

Regarding requires vs. supports ... in WSAD open your "EJB Deployment Descriptor" by double clicking it in Web Perspective.  Click on the "assembly descriptor" tab.  There you will see a "container transactions" pane.  Click add and a wizard launches.  Pick any ejb, click next.  Then you can pick "supports" or whatever other choice you want to try, then select the methods you want to apply it to.  Finish up the wizard.  You can check your ejb-jar.xml source to see what the wizard added for you.

Hi damonf,
Thanks for your insightful reply.   With regard to the EJB descriptor changes, my project is a Web Project so I have a Web Deplyment Descriptor.  I looked for an equivalent to what you described in the EJB Depl Desc but didn't find one.

Re: the runnable code:  I cannot access the code where the thread is spun.  I'm subclassed from it and implement a performTask() method where my service performs its work, including database access.  However, I was able to look up the UserTransaction and then issue a ut.begin() followed by a ut.commit() and this appears to have been successful.  For sure, it did get rid of the warnings.   I had been doing the commit on my pooled connection before and am wondering just how "global" is this transaction?  Will it confine the uow to what occurs between my issuing the begin() and the commit()?    Is it actually a new transaction or is it finding some existing one?

Thanks for your time and help.

I'm not really sure how "global" the transaction is.  I mean, with EJBs you can define whether a method "requires" a transaction, "requires new" transaction, "supports" an existing transaction, etc.  With servlet stuff there's similar concepts but it's all handled by the container.  There ARE some settings, but I'm not sure I fully understand them.  Open your web.xml editor in WSAD and look at the servlet tab.  Click any servlet.  At the bottom right you'll see "IBM Extensions" and some dropdowns for "boundary", "resolver" and "unresolved action".  All these involve transactions.

My practical understanding has been that even when I don't set anything up, there is some type of global transaction in existence surrounding the work I'm doing.  I've become aware of this when there were problems and the error logs talked about transactions (that I hadn't set up) getting rolled back.  Anyway, from what I've seen, calling begin() and end() does seem to have the practical effect of defining the UOW as you want.  That's good enough for me; hope it is for you.

HTH

Damon

Hi again,
I did some more reading and guess the deal is that they really frown on issuing database calls from a separate thread.  I don't have time for this project to try to learn how to use JMS as they advocate but will look into it for next time.  In the meantime, the UserTransactions seem safe enough.

Re: the IBM extensions -- thanks for pointing those out -- I hadn't seen them.  There are similar properties on the References tab too that deal with transaction related work.  I experimented with a few of these but I continued to get the error until I used the ut to define my scope.

My final question on this topic is just to ask if you have successfully used ut's with pooled connections.  I'm only concerned because the commit was previously sent to the connection and now it will be issued to the ut.  I believe in this new scenario, I would only need to get the connection, create and run a prepared statement, then close the connection and the statement.  The commit/rollback would only need to be sent to the ut, right?  Is there any need to commit() the connection as well?

Thanks again.  You have been extremely helpful.