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