Java Reference
In-Depth Information
resources (like JMS and most databases) in a single CMT,
Application Server will take care of the dirty work. It will
make sure that the transaction is entirely done or entirely not
done, including failure cases such as a system crash, database
crash, or whatever. The implementation maintains
transactional state in transaction logs. We can't emphasize
enough the need to rely on CMT transactions if the
application accesses multiple resources. If the resources you
are accessing cannot provide for two-phase commit, then of
course you have no choice but to use a more complex
approach but you should do everything as possible within
your power to avoid this situation.
Take advantage of application server features requiring
no code modification
With features such as Application Server caching and the
Prepared
Statement
cache,
the
performance
gains
are
substantial and the overhead is minimal.
Best practice above states a clear case as to why you should
be very prudent in applying application-server-specific
features that modify your code. It makes portability difficult
and may make version migration challenging as well.
However, there are a suite of application-server specific
features, in Application Server, that you can and should take
full advantage of precisely because they do not modify your
code. Your code should be written to the specification, but if
you know about these features and how to properly use them
you can take advantage of significant performance gains.
For one example of this, in WebSphere Application Server,
you should turn on dynamic caching and use servlet caching.
