Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

EJB transactions  RSS feed

 
Mark Scullin
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi.
I am trying using a session ejb to write to a DB2 database and also call another session bean which updates another db2 database.
The second session bean is called within the transaction of the first session bean.
The method being called is marked as TX_NOT_SUPPORTED. Upon commit i am getting "Illegal use of 1PC resource in transaction".
Reading various manuals my understanding is that the first transaction will be suspended when the call is made to the second session bean (since not supported is set on its methods). Once this second ejb returns the transaction resumes.
According to the redbook SG246144 EJB Development for VAJAVA (page 223) TX_NOT_SUPPORTED will allow methods to run outside an existing transaction context. Once they are completed the transaction is resumed.
This is exactly what we are trying in WAS4.
The second ejb is logging messages to a separate database and its success etc should not rollback the first transaction. I would prefer not to use 2pc resources for performance reasons. I would have thought i didnt need to based on what i have read so far anyhow.
Any one have any ideas ? ie why this is happening or advice on a better way to log these messages without causing transaction issues?
Thanks...
 
Dana Hanna
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Perhaps the second EJB shouldn't throw an exception on an error that causes the problem.
If it's a CMP then you have a problem... There's another solution that I like: If you wrap the call to this EJB around another that just adds the message to log to a Queue (like a LinkedList), you won't have an issue. Then you need a thread reading from the queue occasionally and writing the messages...
I have an implementation of this in a Log4J JDBC appender. No EJB though.
Perhaps using JMS would be an option if you would like to gaurantee that the messages get there eventually. The Log write EJB could just send a JMS message, and a MDB backend could be writing them. Therefore, if the DB goes down, its a non-issue. The MDB can deal with that.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!