*
The moose likes EJB and other Java EE Technologies and the fly likes Steps to be taken in a high transaction environment. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Steps to be taken in a high transaction environment." Watch "Steps to be taken in a high transaction environment." New topic
Author

Steps to be taken in a high transaction environment.

KrishRads
Greenhorn

Joined: May 24, 2005
Posts: 10
Hi,
Assuming that we have a web application which will have a high transactional volume what are the points to be kept in mind during the development process-eg.architecture wise .

Thanks in advance.

KR
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Krish,

There is no standard or easy answer to your question. To answer you shortly (if you think this is shortly :-)) I�d say that it depends. It depends upon a lot of factors, like whether you have distributed transactions or not, depends upon the transactions logic and complexity (basic CURD operation are easier to handle than a transaction that spans a lot of logic), it might also depend upon integration with other systems or legacy applications, etc. Probably in your case one of the first important decisions to take is about the concurrency strategy you want to implement. If your transactions are pretty simplistic in nature, requiring only basic CRUD operation, then you should probably consider allowing the database to handle them. In this case you might not need an application server at all; you just need a powerful database engine and an efficiently clustered web server.
If your transactions on the other hand are logically complex (but not distributed still) then you might consider the option of handling the concurrency "outside" of the database, at the container level. This would be in this case more efficient than handling the concurrency inside the database. The secret is to use caching data as much as you can. But these kinds of solutions are usually outside of the j2ee specs and they represent vendor specific solutions. As an example I�d like you to look at the read-only concurrency strategy and optimistic concurrency strategy that weblogic provides. They both benefit of the fact that the data could be cached between transactions and this is in a totally contradiction with what the silly j2ee specs say (accordingly to j2ee each any transaction starts with ejbLoad and end with ejbStore. Yes it always works but there is no way to provide any caching and it will overkill you application).
Finally if you have distributed transactions, or if you don�t feel happy with any of the solutions above, then think that messahing is one of the key successes for designing this type of highly available and mission critical applications. You can turn your attention to other messaging systems like MQSeries, or you can implement a message fa�ade with ejbs.
However the choice is, you�ll definitely need a powerfull database and a very optimal and efficient cluster.
Regards.


I think, therefore I exist -- Rene Descartes
KrishRads
Greenhorn

Joined: May 24, 2005
Posts: 10
Thanks for your timely reply!!

Regards
KrishRads
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
A few thoughts off the top of my head.
Design and code your application to be distributable, as you will probably cluster it or the EJB server may choose to ditribute the beans. So, no non-final static variables, keep away from singletons ...

Unless there are good reasons why you shouldn't, use only stateless session beans (and MDBs if needed) and optimise the connection pool.

Keep your transactions short, do not fall into the trap of keeping them open during user input! Use CMT in most most cases.

Use a thin JDBC driver.

Cache prepared and callable statements.

Distribute the database workload across multiple disks to avoid or reduce disk overloading.

Optimize disk I/O: selecting a larger block/buffer size for I/O reduces the number of disk accesses.

Consider checkpointing (to periodically flush all dirty cache data to disk).

Use the DB to sort and filter data.

Use servlet caching and GZIP compression.

Precompile JSPs.

Do not use XML to transport data within your application.

Use logging (there should be no system.out.println statements in your code).


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Steps to be taken in a high transaction environment.