Concurrency Testing in Java Applications

Testing and optimizing Java code without test automation for handling concurrent activities is rather difficult. Even with test automation, being able to correlate the test activity from the client side to observations of thread, memory, object and database connection use on the server side is difficult at best. This tool describes methods to test concurrency in Java applications and also displays the new technique for correlating about the task that a Java application server is doing on the server side however a load test automation tool drives a
test on the client side.

Most of the IT managers consent about the concurrency testing that it is the right way to determine many performance bottlenecks, resource contention issues, and service interruptions. However, only few of the
developers use concurrency testing becau se the available test tools are not satisfactory.

New Features in EJB 3.1

New features are added to the EJB 3.1. Experts are trying to make changes to the EJB 3.1 for the next version of the Java EE specification. The idea behind these changes is to provide the head's up on the changes as
well as gather your feedback early so t he expert group has the best chance of getting it right. EJB 3.0 is made simple to Java EE 5 by moving away from a heavyweight-programming model. EJB 3.1 targets to build the successes movement down the path of simplicity along with a handful of much-needed features.

The features added to EJB 3.1 makes the interfaces optional for EJBs and Singleton Beans, but none of the features has been finalized yet; all of this is really just a peek into the inner workings of the JCP so that you have a chance provide early feedback.

1. EJB Interfaces are Optional

In EJB 3.1, now you do not need to define any interfaces for Session Beans, just like JPA Entities and Message Driven Beans. All you have to do is annotate a POJO with the @Stateless or @Stateful to get a fully functional EJB.

2. The Singleton Beans

A new feature of Singleton Beans is added in EJB 3.1 that is used to store application-wide shared data. The JEE container maintains a single shared instance of an EJB 3.1 Singleton that can cache state across the application tier. Like all other EJBs, Singletons are simply annotated POJOs.

3. Support for direct use of EJBs in the servlet container, including simplified packaging options. Like the web.xml file that resides in the WEBINF directory, you would be able to place an EJB jar into the WEB-INF/lib directory.

4. Support for stateful web services via Stateful Session Bean web service endpoints.