Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Steps to be taken in a high transaction environment.

 
KrishRads
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
KrishRads
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your timely reply!!

Regards
KrishRads
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic