How do you determine if the bean is destroyed or created? If you have a
non-transactional method as in your example below, the persistence
context will be created for the duration of the EM call and destroyed
after that.
-marina
Seamus C wrote:
> I'm using Glassfish 2.1 here.
>
> I have a servlet that is accessing a local, stateless EJB that
> performs a JPA findById
>
> It looks it up via this code in the constructor:
>
> FooLocal localEJB = null;
> InitialContext ic = new InitialContext();
> localEJB = (L) ic.lookup("java:comp/env/".concat(ejbName));
>
> It then does a read only operation localEJB.readFoo() in the HTTP get
> method.
>
> The call itself works just fine but I'm seeing two possibly related
> issues:
>
> 1. The stateless session bean always seems to be recycled in the
> pool. In other words, every time I call localEJB.readFoo() it
> destroys a bean in the pool (presumably the one that was
> invoked) and creates a new one. It does this regardless of how
> big or small I set the EJB pool. So basically my stateless bean
> FooBean effectively seems to to be single use - a new one is
> being instantiated every time I call localEJB.readFoo().
> 2. A transaction is committed for each invocation of
> localEJB.readFoo() - I've attempted to turn this off via placing
> pretty much all the combinations of @TransactionManagement and
> @TransactionAttribute on the EJB to no avail. Is this one of
> those things I have to set in the sun-ejb.xml?
>
> For what it's worth, my EJB basically looks like:
>
> @Stateless
>
> @TransactionManagement(TransactionManagementType.BEAN)
> @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
> public class FooBean implements FooLocal, FooRemote {
> public String readFoo() {
> EntityManager em = getEntityManager();
> try {
> em.findById(foo);
> } finally {
> em.close();
> }
> }
> }
>
> public interface Foo {
> public String readFoo();
> }
>
> @Remote
> public interface FooRemote extends Foo {
> }
>
> @Local
> public interface FooLocal extends Foo {
> }
>
> I've simplified the example here obviously but the unnecessary bean
> destroy as well as unneeded TX are killing performance.
>
> Any help would be appreciated!