This article describes a workaround design that allows a Portal to survive if its resource starts hanging request threads. How frequently does your Portal experience user requests hanging in the resource? Not frequently, I hope. However, if this happens and the resource continues hanging user requests, the Portal is exposed to a fatal risk of spending all of the configured concurrent user requests and eventually dies.

Performance testing a J2EE application can be a daunting and seemingly confusing task if you don't approach it with the proper plan in place. As with any software development process, you must gather requirements, understand the business needs, and lay out a formal schedule well in advance of the actual testing.

Maintaining complicated legacy applications is a challenge, which is often made worse by lack of documentation, nonintuitive design, and coding practices. Unfortunately almost all software developers will find themselves with such an assignment at some point in their careers.

This article will provide some useful tips for debugging your BEA WebLogic Server applications when a system core file occurs. It describes debugging tips, problem troubleshooting, and tools available to assist you in this process.

A continuous integration process involves automatic building and testing with tools like Ant and JUnit. These tools need a tool that will manage and control the build process - this is where Cruise Control comes in.

In helping our customers deploy J2EE applications on the mainframe we've learned a number of tips and tricks. We've included configuration settings, tuning suggestions, and descriptions of existing production applications in this article. Although each environment is different, these tips and tricks should jump-start anyone considering a mainframe WebLogic deployment.

This month I'm going to look at some of the things I found in those days when I studied the use of SQLJ with WebLogic 6.1.

If you've had the pleasure of working with BEA WebLogic Server for several years, you may know that RMI/T3 calls between different releases of the server used to be disallowed ­ to be buzzword -compliant, the releases were not 'wire compatible.' For example, you couldn't call an EJB deployed on WebLogic Server 4.5.1 from a WebLogic Server 5.1 application. This often meant that groups of applications had to be migrated together to new versions of WebLogic Server.

We have a J2EE application where clients with the same userid need to share the session data that is maintained on the server side. In addition, clients aren't just Web clients, but applets and applications as well. How should we implement that? This is a typical problem when writing J2EE applications, since the J2EE APIs don't provide an out-of-the-box solution for this.