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