SessionBean non-reentrancy?

[Bjvrn Hamrin]

Can a SessionBean invoke a method on itself through its local or remote interface without violating the non-reentrancy rule?

[bill kemp]

If you do a lookup and create from within one of the SessionBean methods in
the first bean to get a local or remote reference to the same bean, and then
invoke a method on the newly created bean, you will be invoking the second
method on a different instance of the bean, so you will not be violating any
non-reentrancy rule.

The question I have is, "Why would you do that when you can just make a
direct call to the second method from the first method in the first bean
without acquiring a refence to a second bean?".

Bill

Post by Bjvrn Hamrin
Can a SessionBean invoke a method on itself through its local or remote

interface without violating the non-reentrancy rule?

[Bjvrn Hamrin]

Thanks for the reply.

Ok, having two SessionBeans eliminates any reentrancy problem. What I was considering was having only one, by writing code something like this:

public class ABean implements SessionBean
{
public void foo()
{
A a = (A) sessionContext.getEJBLocalObject();
a.bar();
}
..

This is nearly the same as:

public class ABean implements SessionBean
{
public void foo()
{
bar();
}
..

Except that by using the local interface I would expect that transaction attributes and other stuff in deployment descriptors should have effect. In my case I don't want any transaction in foo(), but bar() must have a transaction.

/Björn

[bill kemp]

Interesting. Without trying this I'm only speculating, but I would suspect
the container to throw an EJBException at a.bar(). Have you tried it?

You could accomplish your goal using the second coding style and configuring
the bean to use BMT. That would allow bar() to begin/commit/rollback a
UserTransaction.

Bill

Post by Bjvrn Hamrin
Thanks for the reply.
Ok, having two SessionBeans eliminates any reentrancy problem. What I was
public class ABean implements SessionBean
{
public void foo()
{
A a = (A) sessionContext.getEJBLocalObject();
a.bar();
}
..
public class ABean implements SessionBean
{
public void foo()
{
bar();
}
..
Except that by using the local interface I would expect that transaction

attributes and other stuff in deployment descriptors should have effect. In
my case I don't want any transaction in foo(), but bar() must have a
transaction.

Post by Bjvrn Hamrin
/Björn

[Bjvrn Hamrin]

I just tried calling bar() through the local interface, and it appears to work. At least it works in WebLogic 8.1. Not sure if that is the correct behavior, but I guess will have to assume so. Using BMT is not an option for me because bar() is called from other SessionBeans and must take part in their transactions.

I really wish the EJB standard had more to say on reentrancy, but thanks for your answer.

/Björn

[Rob Woollen]

It's difficult to say without looking at your code in depth, but I'd
consider refactoring ABean into 2 separate classes or EJBs before I'd do
a loopback call like this.

-- Rob

Post by Bjvrn Hamrin
Thanks for the reply.
public class ABean implements SessionBean
{
public void foo()
{
A a = (A) sessionContext.getEJBLocalObject();
a.bar();
}
..
public class ABean implements SessionBean
{
public void foo()
{
bar();
}
..
Except that by using the local interface I would expect that transaction attributes and other stuff in deployment descriptors should have effect. In my case I don't want any transaction in foo(), but bar() must have a transaction.
/Björn