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

EJB and DAO transaction question  RSS feed

 
Ted Bell
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I am refactoring an EJB application here, and have come across a question regarding transactions (and design in general).
The original coder of the application has several instances where he needed to check a table to see if a key was present in that table before inserting a record in another. So he created a stateless session bean in each instance, and in the bean class, coded a JDBC query to the database to return the result. There is no transaction code within the JDBC call, and it obtains a connection via a standard DataSource object.
I want to make sure first of all that even if we demarcate that method in the DD to support (or event require) a transaction on those methods that becasue the SB code obtains its own connection from the pool and has no JTA calls, it does not have any relation at all to whatever transaction the user is currently in. Is this correct?
If I am correct, then I am seriously thinking of refactoring these calls out of the EJB's and into standard DAO's. If I don't need any of the services provided by the container, and these methods will never be called remotely, why go through the burden and overhead of making everything an EJB?
Thanks for any thoughts.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Art Vandelay:
I want to make sure first of all that even if we demarcate that method in the DD to support (or event require) a transaction on those methods that becasue the SB code obtains its own connection from the pool and has no JTA calls, it does not have any relation at all to whatever transaction the user is currently in. Is this correct?
If the user already has a transaction and the EJB method has its transaction attribute as "Required", all JDBC stuff called behind the EJB method go under the existing transaction. So, if I understood your question correctly, it does have a relation to the user's existing transaction.
 
Ted Bell
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the reply, but I'm still a little unsure. Reading the message here leads me to belive that my first assumption is correct. If there is no JTA code within the (Stateless SB) bean method, the bean method obtains a connection from the pool (autocommit still 'true'), performs an operation, and releases that connection back to the pool, how is transaction knowledge passed?
The code in the SB is not dependent on any transaction going on elsewhere. Seems like an EJB for reading this information is overkill.
As an example, I have SessionBeanA which calls EntityBeanB to create a record in a table. Before calling the EB, I want to make sure that a value is present in a totally different table. Why should this query have to be wrapped within the transaction of the EB? Even if it did, it just doesn't seem to me that a simple query as defined above (just because it's in an EJB with tx marked in the DD) would participate in it.
Sorry if I'm dense, just want to be sure I understand this properly before I break something.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Art Vandelay:
If there is no JTA code within the (Stateless SB) bean method, the bean method obtains a connection from the pool (autocommit still 'true'), performs an operation, and releases that connection back to the pool, how is transaction knowledge passed?
When your DAO asks for a connection from the DataSource, the container associates the given Connection object into the current thread's transactional context. The container also disables autocommit for the underlying connection when inside a transaction.
Anyway, you're probably correct in that the session bean is an overkill (unnecessary infrastructure).
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!