• Post Reply Bookmark Topic Watch Topic
  • New Topic

JSF and database transactions  RSS feed

 
A Saari
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,


I'm new to JSF and am having trouble understanding how to handle database connections and transactions (I have a SWING background).

// these are just a few of the files in the project
projects.jsp
handleProjects.java // the backing bean (contains a modelProject object)
modelProjects.java // where all the db code is


When the user goes to the projects.jsp page an instance of handleProjects is created - it in turn creates an instance of modelProjects using a projectID passed in. modelProjects does a SELECT and makes all the project data available to handleProjects - and all the data shows up in the projects.jsp in 'view' mode. Fine so far.

When the user selects 'edit' mode, the handleProjects object calls modelProject.lockProject() --- and that method does a SELECT ... FOR UPDATE to row-level lock the database data.

The user can now edit the data for the project being displayed. Once the user clicks the 'SAVE' button, the data is sent to the handleProjects object and it in turn sets the data in the modelProjects object and calls modelProject.saveData() - which releases the lock when it's done.

In order to maintain the lock in modelProjects, I have to keep the connection to the database open ---- but what happens if the user exits the browser without hitting the 'SAVE' button? What happens if the user starts clicking the 'Back' button and begins working on another project? In SWING I'm in the same process space so I can handle all that stuff - I don't understand how to do it when part of the application is running in a separate space on a separate machine (i.e. in the browser).

I've read that some applications do a SELECT without locking, allow the user to edit the data and then check for a 'dirty' condition (i.e. someone else changed the project data while my user was editing the same project).

Can someone point me to a JSF discussion on the above?

Any thoughts greatly appreciated.

Amy
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well the first thing to understand is that there's a BIG difference between client/server and HTTP. This is tru whether you're taling JSF, struts, plain servlet/jsp or even Perl.

Unlike client/server or local MVC apps (like Swing) each request to an http server stands by itself. Also, http can never volunteer things, only respond to requests, so "real" MVC is impossible.

So we fake it. we use platform assists like JSF to make our task easier, and we keep state in a session object.

But there's a catch. In order to work reliably, you should never store anything in a session object that isn't serializable. JDBC Connection isn't serializable because it's an interface, not a class. It wouldn't be a good idea anyhow, since you'd end up keeping a lot of expensive resources tied up. And, as you noted, someone can just walk away from a site. Which means that resources would remain tied up until the session times out and is discarded by the server.

Generally, the ways around this involve either caching the data objects in a session (which only works if the data involved is smalll/few users) or you cache the search terms in the session and re-query on each request. Which sounds bad, but modern systems understand this problem and are optimized for it.

I'm working on a similar problem myself right now. You're not alone.

As far as the locking goes, you have no way of knowing whether the user is gone for good or not anyway. you might set up a lock table and enter keys of "locked" records into it and then you could unlock them with a session listener if they didn't respond with a commit/cancel request in time. That way you wouldn't have to hold a connection between requests.
 
A Saari
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim

Thanks for the reply.

I thought to control access to the database by using a static ArrayList of projectID objects in the projectsHandler. The handler then accesses the projectsModel class inside a synchronized block

private static ArrayList lockedProjects = new ArrayList();

....

synchronized ( currentProject ) {
if ( lockedProjects.contains(currentProject.getProjectID()) ) {
// Tell the user the project is locked.
} else {
lockedProjects.add(currentProject.getProjectID());
}
}
....

synchronized ( currentProject ) {
currentProject.saveProject(); // database UPDATE
lockedProjects.remove(currentProject.getProjectID());
}

now I need to make it smarter - so I can 'time out' locked projects. I wonder if I should write a servlet to handle locked projects - like those old servlet-based db connection poolers???

Thanks again...
amy
 
Gerardo Tasistro
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can't you make it lock just at you get the form submitted?

User requests info
Server queries dbase and returns info
User edits it (very long time could pass here)
Server gets post and within the same request
-locks table
-updates values
-releases lock

That way your lock never depends on the user post. Of course depending on what you have to update and how you could have some issues here. This is the "dirty" situation you'd be talking about, but that could be dealt with in the "update values" code.

This problem BTW isn't specific to JSF. Any web based app has this issue. Locking resources between requests is a very bad idea.
 
A Saari
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, if I control access to the project data in the handler and sync the update method I don't really need to lock the table at all. Assuming my jsf interface is the only way into the data, I don't need to worry about a dirty read either. Now I'm left with how to time-out the 'lock' in the handler if the user gets up and walks away.

And I agree - this is not really a JSF issue...perhaps I should have posted it to the Servlets list.

Amy
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!