Re: EJB Transaction
Karen Low <[email protected]> Fri, 18 Aug 2006 12:24:31 +0800
| Newsgroups | gmane.comp.java.sun.ejb.general |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_14155_29750862.1155875071422
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Thank you very much, JP, for the more detail info!
The web application that I'm working with previously has a huge deadlock
problem, which leads to database hang, application server (SunONE) also
hang, we tune at the DB level, still find the application server hang at
some point (at about 100 concurrent users). So, I'm checking on the
possibility of where has gone wrong .. (I'm not an experience Java developer
yet :) )
One more question to ask, still referring to the below diagram:
Action class (Servlet):
---> Stateless Session Bean (1)
---> POJO
---> Stateless Session Bean (2)
---> POJO (DAO) ==> DB (insert)
---> Stateless Session Bean (2)
---> POJO (DAO) ==> DB (update)
Let's say at some point the DB hangs and throw the exception to SLSB2 and
SLSB2 did not do anything but just PrintStackTrace, will the running thread
ever complete in this case? Cause SLSB2 never returns anything once it
catches the exception other than just print the stack trace. If this keep
happening, do you think it's a possibility where it'll make the app server
hang?
What do you think?
Thank you.
Regards,
Karen
On 8/17/06, JP Lorandi <[email protected]> wrote:
>
> 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".
------=_Part_14155_29750862.1155875071422
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Thank you very much, JP, for the more detail info!<br><br>The web application that I'm working with previously has a huge deadlock problem, which leads to database hang, application server (SunONE) also hang, we tune at the DB level, still find the application server hang at some point (at about 100 concurrent users). So, I'm checking on the possibility of where has gone wrong .. (I'm not an experience Java developer yet :) )
<br><br>One more question to ask, still referring to the below diagram: <br><span class="q"><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)</span><br><br>Let's say at some point the DB hangs and throw the exception to SLSB2 and SLSB2 did not do anything but just PrintStackTrace, will the running thread ever complete in this case? Cause SLSB2 never returns anything once it catches the exception other than just print the stack trace. If this keep happening, do you think it's a possibility where it'll make the app server hang?
<br><br>What do you think?<br><br>Thank you.<br><br>Regards,<br>Karen<br><br><div><span class="gmail_quote">On 8/17/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>> Thank you, JP, for the valuable information!<br>
><br>> You mentioned: "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)"
<br>><br>> POJOs obtain the Datasources in the sanctioned way means only through<br>> InitialContext lookup only? Must be a JNDI lookup only? DriverManager<br>> way will not make the call from the POJO DAO falls into the same
<br>> transaction?<br>You MUST use JNDI (or some other way your app server supports);<br>DriverManager by itself WON'T WORK. The EJB container needs a place<br>where to intercept the call that obtains the connection, so that it can
<br>enroll it in a transaction.<br><br>To be more graphical, when you get a DataSource in an app server, you<br>get a class the container creates with code equivalent to this (this<br>would be the most common code):<br><br>
class ASDatasource implements Datasource {<br> private Datasource original;<br> public ASDatasource(Datasource original) { //gets called by JNDI<br>implementation<br> this.original = original;<br> }<br> public Connection getConnection() { //gets called by EJBs
<br> ASThread t = (ASThread) Thread.currentThread(); //gets the App<br>Server's EJB Container current Thread; it's a custom class<br> ASTransaction tx = t.getCurrentTransaction(); //the custom class<br>holds the current transaction for this thread
<br> Connection rval = original.getConnection();<br> tx.enrollConnection(rval);<br> return rval;<br> }<br>}<br><br>So, the current Transaction is held by the current Thread (or might be<br>in a Map where the current Thread is the key, etc)-- thus it's commonly
<br>said that the Transaction has "Thread Affinity" (in most bibliography).<br>When you get your resources (Datasources, Connectors, etc) via JNDI, you<br>give the container the chance to work its magic so that every connection
<br>you use gets enrolled to a different transaction. This is also why the<br>spec prohibits launching new Threads from within EJBs: it can't be<br>guaranteed that the new Threads will posses the normal transactional<br>properties of ASThreads (among other reasons).
<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<br>> 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>Yup that would work perfectly, as long as you're using JNDI and<br>demarcating the methods correctly (Required).
<br><br>HTH,<br>JP<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_14155_29750862.1155875071422--