very serious Synchronization issue....urgent

[shikhar singh]

I have just completed a big project on E-CRM, but in the end stage of our project we realized that there was flaw in our approach, which is turning out to be very dangerous. My JSPs are not threadsafe and global variables are declare in most of the jsps moreover jsps are included with global functions (within <%! %> tag). These global functions as well as service method accesses these variables.
We deployed our application at customers site but now under heavy loads we are facing synchronization problems. Like entry of one user sometimes interchanges with the entry by other user. This happens when both the operations are done at the same time and there is heavy load on the server. This is obviously a very serious bug.
I can follow two approaches:
1. make all the jsps threadsafe by synchronizing the service method: but this will reduce the performance (i am using weblogic server).
2. make all global variable declarations with in the service method and pass the same in whichever global functions it is required : but over project is a huge one (around 700 Jsps), this will involve a huge amout of changes, which we can't afford at this time.
So, point 2 is out of question.
Brecause this seems to be a very common problem, can somebody tell me what is the best solution to deal with this. Is there any other way other then above two points..
This will be a very very big help to me..
Thanks a lot in advance..

[vaibhav punekar]

The ways to treat these problems......
1)To define the variables in JSP where they are needed instead of declaring them as "class level".
2)Try to put your "problematic" code into "synchronized" block.
3)Or implement "SingleThreadModel" ie change the default value of "isThreadSafe".It will certainly affect the performance.
4)Session variables inhtis case can come to your rescue.Put the values in session variables and remove them immediately after use.or invalidate the session.
5)Have you used three tier architecture?I thnik for heavy traffic it is always advisable.But that does not seem feasible now.
Are there any other ways?Please let me know gurus.This is a very common problem we face at the end of the project when the customer do "rigorous" testing.

[Peter den Haan]

Originally posted by shikhar singh:
[...] I can follow two approaches:
1. make all the jsps threadsafe by synchronizing the service method: but this will reduce the performance (i am using weblogic server).
2. make all global variable declarations with in the service method [...] point 2 is out of question.

Well, point 1 is out of the question too. As you pointed out performance would go down the drain. That's why Sun made it possible to
3. tag all the jsps as non-threadsafe using <%@page isThreadSafe="false" >. This is the JSP equivalent of implementing SingleThreadModel in a servlet. The servlet engine will instantiate your JSP (servlet) multiple times if the load gets high.
A couple of things to keep in mind.

• This solution will only work if your code doesn't make the (implicit) assumption that the JSP is a singleton, i.e. that there is only a single copy of the JSP alive at any one time. If your code does make this assumption, you will have to either modify your code or synchronize the service method.
  
• There is an obvious tradeoff between performance and memory usage. Instantiating the JSP/servlet multiple times will eat memory. Increased load will translate directly to increased memory requirements, not the best of scaling behaviour. Be prepared to stick a lot of memory in your server box(es).
  

My suggestion for a plan of action would be the following.



• Determine which JSPs are receiving the highest traffic. Since the application is live, you have the luxury of having accurate information about this. Use it! You will probably find that a handful of JSPs get 80-90% of the traffic; rewrite these using option 2.
  
• Synchronize the service method on all other JSPs (option 1 - a slow application is better than a defective one).
  
• Test and release (optional). This will get a functioning with reasonable performance up and running as quickly as possible.
  
• Go through the now-synchronized JSPs and give each a careful eyeball. If it is very clear that the code does not make assumptions about being a singleton, you could tag the page as not threadsafe (option 3) and remove the service synchronization. If it is making assumptions, or if you want to reduce memory footprint, see if there is a possibility of synchronizing just the non-threadsafe code. If you are not sure, leave the service method synchronized as-is.
  
• Test and release.
  
• Fire the project manager who allowed a 700 jsp project to get to this stage without organising code inspections by a (possibly external) J2EE guru.
  
• Make a plan for refactoring the application, as it is by now likely to be in a sorry state.
  

This is not an exhaustive list, but just what I can think up offhand.
Good luck
- Peter

[This message has been edited by Peter den Haan (edited April 19, 2001).]

[Jason Menard]

700 jsps?! Does this mean you guys embedded all your code in jsps? Just out of curiosity, did you guys use MVC architecture, or is it just flat page-centric, or some other architecture? If the jsps were used simply as the view, I'm having a hard time imagining an application with 700 totaly distinct views. If that's what you guys did that sounds like a nightmare to maintain.
In my experience I have found the controller servlet(s) with data beans and jsps as the view to be very easy to maintain, but that's just personal opinion.
Anyway, I was just curious.

[shikhar singh]

Vaibhav, Peter, Jason
Thanks a ton for these suggestions. I learned a lot from your adivices. I've gone thru each words of yours and we have already started fixing this.
By the way I have following queries:
1.(As Vaibhav said) How do i explicitly kill my session variable and session itself?
2.(As Peter said :inspections by a J2EE guru.)How can i get a external java Guru who can inspect my application's architecture?
3.(As Jason asked me oes this mean you guys embedded all your code in jsps)
No not exactly. Actually we ported ASP/C product to JSP/Java. So basically we inherited this thing from previous product. Java code is heavily embedded in our JSPs. Still we are using javabeans, which just routes the call to server classes. I know the advantages of MVC model but its too late to implement this. Can you suggest some place(site), where I can get information about, better ways to design and write JSP driven applications.
Thanks a lot again.

[Peter den Haan]

Originally posted by shikhar singh:
1.(As Vaibhav said) How do i explicitly kill my session variable and session itself?

request.getSession().removeAttribute("myBean");
request.getSession().invalidate();
Storing state in session- request- or page-scoped objects rather than the JSPs itself is the Right Way To Do It, but it is definitely your option 2 -- time and risk are probably higher than you can afford for the full 700 pages.

2.(As Peter said :inspections by a J2EE guru.)How can i get a external java Guru who can inspect my application's architecture?

Are you based in India? Personal interaction between the guru and your developers would be valuable, I think, so I cannot give you any recommendations (I'm UK based currently). Many companies seriously involved in J2EE projects have their resident guru(s), and most will lend you one... at a price... One way to track one down is to hazard a post in "Jobs Offered" here on the 'ranch.

3. [...]Can you suggest some place(site), where I can get information about, better ways to design and write JSP driven applications.

There are worse things than keeping track of the 'ranch Saloon...
One way to learn more is to take a look at a GOOD MVC framework like the Struts framework which is part of the Apache Jakarta project.
Another way is to browse through the articles on Sun's Java Developer Connection.
Finally, there are several good books on the market. I tend to agree pretty well with the recommendations in the Bunkhouse here at the 'ranch. Amazon's user reviews are worth your while too.
Good luck
- Peter