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?
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)
Thanks again.
Regards,
Karen
On 8/16/06, JP Lorandi <[EMAIL PROTECTED]> wrote:
Karen Low wrote:
> Action class (Servlet):
> ---> Stateless Session Bean (1) ---> POJO ---> Stateless Session
> Bean (2) ---> POJO (DAO) ==> DB (insert)
> ---> Stateless Session Bean (1) ---> POJO ---> Stateless Session
> Bean (2) ---> POJO (DAO) ==> DB (update)
>
> Legend:
> ---> calls a method
> ==> DB sql execution
>
> All EJBs are container managed with transaction attribute set to
> "Required". All classes mentioned above are packaged into one ear and
> deployed into 1 app server.
Caveat: My responses assume that the DAO component obtains Datasources
via InitialContext. Otherwise, kiss all transactionality goodbye. In
many app servers, this will mean that SLSB2 must also declare the
Datasource as a required resource (in ejb-jar.xml)
>
> Considering the above scenario, will all the method calls above falls
> into 1 transaction?
No. Each is a separate transaction.
> Is rollback possible in this scenario?
Not atomicly. You'd have to manually code a "transactional saga"; that
is, if the 2nd transaction fails, you must execute an anti rollback for
the first transaction yourself (in this case, a delete operation). It's
a can of worms. Don't try this.
> Are they consider in the same session?
Nope. Incidentally, the "correct" term (or should I say most widely used
in bibliography) is transactional activity. Transactional activity
starts when within a thread of execution, an EJB method marked as
Required/RequiresNew is called, and the transaction is committed when
the method returns. In your scenario, the servlet fires a transactions
with each call to the SLSB1, which are committed when the method returns
(without throwing an exception); thus, you're firing 2 different
transactions.
> If the ear is deployed into the same application server, even to
> different container (serlvet deployed to servlet container, EJBs
> deployed to EJB container), are the objects sharing the same JVM?
That depends and the spec is worded carefully so as not to assure that.
In my experience this is rarely the case and everything runs on the same
JVM; However, unlike regular java apps, the classpath isn't flat, to
accomodate to different versions of classes in different modules.
Usually classes present in the EJB-JARs are accessible from the servlet
container. The opposite for those available in the war (jars in
WEB-INF/lib or classes in WEB-INF/classes) cannot be seen by the classes
on the EJB-JAR. Classloaders are hierarchical like this:
EAR Classpath <-- EJB-JARs <--- WARS
WARs: can see themselves (WEB-INF/lib, WEB-INF/classes) AND all EJB-JARs
AND The EAR classpath
EJB-JARs: can see themselves AND The EAR classpath.
There may be "weird" deployment cases and/or "weird" servers; if you're
just starting out with EJBs, this is pretty much the typical scenario
and I have this posted in the wall in the office for newbies to check as
it is confusing until you're familiarized with it. Just follow the
arrows, if you want class something in the wrong direction stop and
think a bit about repackaging your classes.
To make it more clear, assume a .ear has:
a.jar (includes class A) (EAR classpath)
ejb.jar (includes class B) (EJB module)
war.war (includes class C in WEB-INF/classes) (WAR module)
C can use classes A and B
B can use class A, but C will yield ClassNotFoundException
A can't use B or C, yields ClassNotFoundException
>
> I have read about EJB transactions, but the information that I found
> are mainly for EJB to local/remote EJB kind, is there any information
> that you can recommend me to read about transaction behaviour that
> relates to EJB to POJO or vice versa?
Read the spec carefully, and post on the list if you have more questions
(also you might check the list archives between 2000-2003). Essentially,
as long as your POJOs get resources properly there's no difference with
the bibliography you already have. I'll present one possible solution to
your scenario here. Remember:
Transactional activity starts when within a thread of execution, an EJB
method marked as Required/RequiresNew is called, and the transaction is
committed when the method returns. Further calls WITHIN THAT METHOD to
other EJBs methods marked as Supports/Requires/Mandatory are enrolled in
the existing transaction.
Action class (Servlet): -->
SLSB3 {
---> Stateless Session Bean (1) ---> POJO --->
Stateless Session Bean (2) ---> POJO (DAO) ==> DB (insert)
---> Stateless Session Bean (1) ---> POJO --->
Stateless Session Bean (2) ---> POJO (DAO) ==> DB (update)
}
So, the servlet calls a single method, say doUseCaseA() in SLSB3. This
starts a transaction. 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). If no
error ocurrs, transaction is committed. If error ocurrs (usually, a
RuntimeException or a subclass is thrown), or the transaction is rolled
back manually, the transaction is aborted, and this spans all DB
operations executed so far. This would be the most common fix to your
scenario.
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".
