Ok, thank you Jim and David. This is the way I manage database access, its approach is inherited from the previous application version and I'm planning to change it:
We use JDBC via JTurbo 4 type driver (no ODBC connectivity). We have a ConnectionObject with a java.sql.Connection attribute, the necessary methods to connect, disconnect and get the java.sql.Connection attribute, and other fields to maitain information like client IP adress etc. A LoginAction creates a ConnectionObject, passes it login and password and calls its connect method. Then creates a UserObject that receives the ConnectionObject. UserObject uses ConnectionObject to search the user in database. Once the user is found the LoginAction put both objects into session via session.setAttribute(...) method. Theese are the only two objects that are tied to the session. The rest of the actions have all the same scheme: get ConnectionObject and UserObject from session, validate user permission to perform the operation, create a business object and pass it the ConnectionObject. The business object uses it to make the necessary database calls. So each session has its own ConnectionObject instance with its own java.sql.Connection instance. The DriverManager.getConnection call is permormed into the ConnectionObject when LoginAction is executed. This connection is never closed during session life. ConnetionObject implements javax.servlet.http.HttpSessionBindingListener. ValueUnbound method is implemented and here is where connection is closed since this method is called when session expires. I know that this is not the better way for perfomance and saving memory at all, but I never thought that this might cause a multithreading issue since each session has its own object instances and nothing is shared between them. Can you explain me how a a multithreading issue can happen under theese circumstances? In order to change to a connection pooling approach: Do you think is a good idea to adapt the ConnectionObject to get and free pooled connections instead of only one openned per session? Or do you suggest to dramatically change all my database access policy. Thank you On Wed, 8 Sep 2004 13:14:39 -0400, David G. Friedman <[EMAIL PROTECTED]> wrote: > How are you doing the database interactions with your MS SQL Server? JDBC > with some ODBC connectivity kit or some other way? > > Regards, > David > > > > -----Original Message----- > From: calandraca [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 08, 2004 1:04 PM > To: Struts Users Mailing List > Subject: strange random problem > > Since I have rewrited an important part of my application using struts > I've had this problem several times. It didn't happen in development > environment, with only one or two users using the application at the > same time. It happends in production with 20 or 30 users. > > * Development environment: Debian GNU/Linux, Jonas 4.1.2 application > server with Tomcat 5.0.25, J2SE 1.4.2, Struts 1.1, MS SQL Server (on > different Win2000 machine) > > * Production environment: Win2000 SP4, Jonas 4.1.2 application server > with Tomcat 5.0.25, J2SE 1.4.2, Struts 1.1, MS SQL Server. > > All forms are request scoped (I think I don't need session, probably > I'm saving memory). Every of them have implemented the reset method > setting variables to their initial values, this is made in > constructors too. > > * This is a bit more complex so I'll try to simplify the explanation > with a generic example: > > 1. I have one object wich instances can be edited and updated by > users, saving its instance values to a database. I have two actions: > EditObjectAction and UpdateObjectAction, each of them with their forms > (EditObjectForm and UpdateObjectForm). > > 2. EditObjectForm has only one String attribute that contains the > primary key (id) of the object we want to edit, submitted from a jsp > page. > > 3. EditObjectAction gets the primary key from the form, instances the > object and call the necesary methods on it in order to load the rest > of object data from database. Then the action put the object in the > request using request.setAttribute("objectName", object) method and > makes a forward (using mapping.findForward(...)) to the page data.jsp. > > 4. Into the data.jsp page I render the view using struts-html, > struts-html-el and c (JSTL) taglibs, extracting the necessary > information from the request object using JSTL expressions like: > <c:out value="${objectName.attribute}"/>. The <html:form/> tag has > this content: > > a) Primary key: <html-el:hidden property="id" value="${objectName.id}" > /> > b) Rest of object data using <html_el:text/> and other useful > tags like loops etc. > > 5. When the user change and submits the data, UpdateObjectForm is > created and filled by struts, content validated, and passed to > UpdateObjectAction. The action takes the id from the form and > instances the object again from database, it updates object values > from the form in memory and database, puts the object into request and > forward to data.jsp again. > > 6. Data.jsp is rendered from the request object again with the new > submitted data. > > Note that the object is NEVER stored into the session. Forms are > request scoped. The only information I keep into session is the logged > user. I don't use application scope. > > The problem is that sometimes (about 10% more or less), once the > object is updated, the next view shows data from another different > object instance that is currently being managed by other user. The > forward or the render fails. I thought about a possible coding or > design error, but is it not impossible to access data from other > session? moreover the object is stored into request. Am I using struts > in a correct way? Could it be a taglibs or struts bug or configuration > error? What do you think about trying struts 1.2.2 or using linux in > production? I think probably is much more easy but I don't see it. > > Thank you in advance > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
