Re: Using Java EE Connection Pools

Just use the servers connection pool by looking up
ressources via JNDI.

If you need to control the transaction handling you need
to specify the session bean as being BMT not CMT.

Thanks Arne, ...I've learned a few things in the past week that make
me wonder if I've approached the problem incorrectly. Allow me to
elaborate for anyone who's following in my footsteps.

With JDBC you get a connection to a database, and with it, one can
engage in transactions, doing database commits, etc.

Your message about BMT (Bean Managed Transactions) and CMT (Container
Managed Transactions) led me to understand that a JBoss Transaction is
_not_ a database transaction, but rather a unit-of-work transaction.

Such things make perfect sense in the context of viewing a EJB as a
piece of business logic, and that a transaction starts when you call a
method, and a transaction ends when the method returns. The reason
for the kinds of transactions is for the case when one bean calls
another: is it the same transaction, are the transactions wholly
independent, is there a dependency between transactions,...

My little problem is that my bean is stateless and, here's the
sticking point, is not trying to persist itself. It's just a piece of
code that gets triggered, to which it sits in a large loop reading
from a stream of near endless data and writes what it's finding
relevant to a database, stopping when it's reached enough.

Knowing that JBoss managed its own persistence by use of connection
pools for efficiency, I'd hoped to tap into the same resource, doing
whatever I wanted with the raw database connection, returning it to
the pool when done.

What's seemingly complicating the matter is that because this is
happening inside of a bean, it is automatically wrapped in a JBoss
Transaction. And, since I'm using a resource obtained from JBoss (the
database connection from the JNDI), it is complying with the implied
transaction. Meaning, no matter what I write, nor how much I close,
the data does not make it into the database until the first entered
method finally exits -- which, as I said being in a loop, can take a
while.

Is there a way, perhaps with class or method annotations to indicate
to JBoss that I don't want my bean persisted, that I don't want it
wrapped in a transaction, and that I'd like a raw database connection
from the pool? (I see by the JMX console, it's got about 20
connections sitting in the pool just waiting to be used.)

Thanks again; replies from anyone are helpful and encouraged.
-Walt Stoneburner, wls@xxxxxxxx

.

Relevant Pages

  • Re: J2EE - entities - When do JPA entity units get saved into the database
    ... as JPA entities and EJB 2 Entity Beans have ... field changes back to the database if the changes occur within the ... same transaction that the entity was loaded in AND if the object has ... However, if the value of 'bean' escapes out of an ongoing transaction, ...
    (comp.lang.java.programmer)
  • Re: Using Java EE Connection Pools
    ... With JDBC you get a connection to a database, and with it, one can ... Your message about BMT (Bean Managed Transactions) and CMT (Container ... Managed Transactions) led me to understand that a JBoss Transaction is ... Knowing that JBoss managed its own persistence by use of connection ...
    (comp.lang.java.databases)
  • Re: Using Java EE Connection Pools
    ... Managed Transactions) led me to understand that a JBoss Transaction is ... relevant to a database, ... database connection from the JNDI), it is complying with the implied ...
    (comp.lang.java.databases)
  • Re: ADO.Net Connection Pooling Problem with Oracle
    ... component that I use for database updates. ... This component's Transaction ... will create a new database connection for every new COM+ transaction. ...
    (microsoft.public.dotnet.framework.adonet)
  • BMP and order of operations in transaction
    ... could anybody help me how to set the order of updates in a ... I have a session bean which updates two entity beans A and ... When the transaction is beeing commited the bean B is updated before ...
    (comp.lang.java.beans)