Implementing multi-tire application and persistent DB connection in WebLogic

[Howard Zhao]

Hi
It seems quite difficult for me and I hope people here can help me find out the solution.
I am working on a project, which is coded according to J2EE specification.
applet -- http --> servlet --JDBC --> DB.
The applet sends request to servlet via http, then the servlet picks a JDBC connection up from connection pool, gets data from DB and sends data back to applet.
My questions is
Since the applet will change data to DB( insert, update, and delete), for case of mistakes, http connection failure or system crash, the DB needs to know when to commit or rollback the changes. The data are sent from applet at different time, each time, a new http request is send, a new servlet session is generated and a new DB session is created. At my current application, from applet standpoint, the possible commit or rollback can only be done at one http request.
Now, in order to keep the DB integrity, I need to commit or rollback DB cross http requests. How to do this? Is there a two-way talk at http level or servlet level? How can I keep same JDBC connection cross-different servlets? Will stateful session bean do this?

[andy armstrong]

I am new to this but here is an attempt at an answer...
This is an example of where to use a UserTransaction . You
should set up a TXDataSource and a Transaction in Weblogic you can retrieve by JNDI. Use this datasource and transaction to peform JDBC connections.
Can someone supply the details?
Cheers,
Andrew
--------------------
scp2, scea, scwcd

[Howard Zhao]

Hi
Maybe I can create a static hashtable which contains the connection object. When servlet processes requests from applet, the servlet goes to the hashtable
to retrieve the connection. In this way, I can say that for different http sessions, they can share same JDBC connection and DB seems to be serving in one database session. Of course,the servlet needs to tell whether http requests are from same applet client by using cookies.
Am I right? Is there some limitation on this idea?

[andy armstrong]

You do not need to store the Connection object just the UserTransaction
object you retrieved from the app server. You could put this in the Session
and just ensure you commit, rollback or end it when the session is finished.