In a clustered environment, it is sometimes necessary to limit to one instance of an EJB or CDI bean for an entire cluster.

When it comes to clustering and distributed computing performance, some of the challenges you have to overcome involve cache invalidation and coordination. Fortunately, both Payara Server and Payara Micro come with EclipseLink, which supports cache coordination and invalidation out of the box. This blog will explain how to configure this feature for your Payara Data Grid.  We would also like to thank Sven Diedrichsen who is the community member that created the Hazelcast cache coordination.

Many applications, especially complex legacy ones that are packaged with a large number of libraries, may contain libraries that are also shipped with Payara Server (like Google Guava or Jackson for example). These types of conflicts can be very hard to track down and solve. Starting from the  171 release of Payara Server, there is now another solution in the toolbox which can help with resolving these dependency conflicts.

In prior releases of Payara Server, it was not possible to control the maximum number of concurrent Stateless EJB instances in Payara Server. It was, however, possible to control the number of pooled Stateless EJB instances, as well as concurrent MDB instances. These features were available in Oracle GlassFish Server 3.1 and earlier but not in the GlassFish Open Source editions (3.1.2.x and 4.x).

In the current release of Payara Server (171), it is now possible to limit concurrent Stateless EJB instances that are dispatched, allowing fine-grained control of resources, limiting surface area for DDOS attacks and making applications run more smoothly and efficiently.

Any project, large or small, would ultimately like to follow industry best practices, such as continuous deployment.  In order to support this, applications must be deployed early and often.  This, in turn, triggers downtime and the users get affected by it because they could be logged out of the website, or worse, their work gets lost because the application's intermediate state is not saved - never mind the actual downtime during the application deployment process.

Rolling upgrades solve this problem in an efficient way!