Karen Low wrote:
Thank you, JP, for the valuable information!
You mentioned: "Calls within this method (directly or via POJOs)
to other EJBs marked as Requires are enrolled into the same transaction
(provided the POJOs obtain the Datasources in the sanctioned way)"
POJOs obtain the Datasources in the sanctioned way means only through
InitialContext lookup only? Must be a JNDI lookup only? DriverManager
way will not make the call from the POJO DAO falls into the same
transaction?
You MUST use JNDI (or some other way your app server supports);
DriverManager by itself WON'T WORK. The EJB container needs a place
where to intercept the call that obtains the connection, so that it can
enroll it in a transaction.
To be more graphical, when you get a DataSource in an app server, you
get a class the container creates with code equivalent to this (this
would be the most common code):
class ASDatasource implements Datasource {
private Datasource original;
public ASDatasource(Datasource original) { //gets called by JNDI
implementation
this.original = original;
}
public Connection getConnection() { //gets called by EJBs
ASThread t = (ASThread) Thread.currentThread(); //gets the App
Server's EJB Container current Thread; it's a custom class
ASTransaction tx = t.getCurrentTransaction(); //the custom class
holds the current transaction for this thread
Connection rval = original.getConnection();
tx.enrollConnection(rval);
return rval;
}
}
So, the current Transaction is held by the current Thread (or might be
in a Map where the current Thread is the key, etc)-- thus it's commonly
said that the Transaction has "Thread Affinity" (in most bibliography).
When you get your resources (Datasources, Connectors, etc) via JNDI, you
give the container the chance to work its magic so that every connection
you use gets enrolled to a different transaction. This is also why the
spec prohibits launching new Threads from within EJBs: it can't be
guaranteed that the new Threads will posses the normal transactional
properties of ASThreads (among other reasons).
Just want to check if I understand what you said correctly.
Also, I was wondering, instead of writing a SLSB3, does the following
works? Is it similar to SLSB3 method that you suggest?
Action class (Servlet):
---> Stateless Session Bean (1)
---> POJO
---> Stateless Session Bean (2)
---> POJO (DAO) ==> DB (insert)
---> Stateless Session Bean (2)
---> POJO (DAO) ==> DB (update)
Yup that would work perfectly, as long as you're using JNDI and
demarcating the methods correctly (Required).
HTH,
JP
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
