Re: Using Java EE Connection Pools

walt.stoneburner@xxxxxxxxx wrote:
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.

Database transactions can participate in a app server
transaction.

But the app server needs to be able to work with multiple
databases.

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,...

You specify transaction behavior in the deployment descriptor.

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.

Session beans are not supposed to sit in a loop reading.

Have you considered a message queue and a message driven bean ?

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.)

BMT.

Arne
.

Relevant Pages

  • Re: Help - Timing Logic
    ... server application, both of which ran on the same box. ... the client applications and 'lodging' them in the database. ... Another part of the server application was dedicated to retrieving messages ... commit transaction ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Help - Timing Logic
    ... put a trigger on the database table. ... Transaction and Database Locking - look at isolation levels / settings ... Maybe implement a message broker ... ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Help - Timing Logic
    ... build a trigger on the database .. ... Transaction and Database Locking - look at isolation levels / settings ... If you need to implement a locking mechanism / or / logging mechanism / or / a checking mechanism to avoid duplicate messages caused by multi-threading ... ... message broker gets all the necessary messages or message id's from the database to be sent ... ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Help - Timing Logic
    ... put a trigger on the database table. ... Transaction and Database Locking - look at isolation levels / settings ... Maybe implement a message broker ... ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Help - Timing Logic
    ... If you need to implement a locking mechanism / or / logging mechanism / or / a checking mechanism to avoid duplicate messages caused by multi-threading ... ... Is it the READ from the database ... ... Perhaps a stored proc may be faster to execute and return the values as opposed to building the transaction in the code. ... implement as above locking only the records you retrieve / update - need to watch out here for table locking ... ...
    (microsoft.public.dotnet.languages.vb)