Can Stateful Java EE 6 Apps Scale? - Another Question Of The Week
Another good Java EE 6 question:
I found the Gateway and PDO patterns to be very interesting, and have proposed to use them on a project at my company. As you predicted in the book, the Gateway pattern has “met resistance” J. I have a couple of questions which would be great if you could take the time to answer. [...]
- Do you see the Gateway pattern as something that could be used in Internet applications, or is it mainly suitable for in-house enterprise apps (behind firewalls)?
The main concerns are
A) Security – it would be safer to have the Presentation layer and BL layer on separate physical machines so that the frontend cannot access the DB directly
An application server usually operates behind a WebServer (apache) and so behind a firewall. It communicates with protocol like mod_jk. Splitting the WebContainer and EJBContainer in different processes
doesn't increase the security significantly, except you want to have another firewall between the presentation and the business logic. My recommendation is: don't distribute.
B) Scalability – the number of entities in the session might consume too much memory
You are absolutely right. Stateful architectures do require more memory, so it is absolutely necessary to perform a stress test to get a rough estimation. A quick test with visualvm can give you an idea how much of memory your application will consume. In the practice you will hardly find stateless applications. Stateless only means, that the entire state is stored in the database and has to synchronized on every request. Stateful means that you cache some data between requests.
The only trouble you may ran into is the overhead associated with HTTP-Session and Stateful Session Bean replication in a cluster environment. In general I do not use state replication in a cluster. In worst case (the server crashes), the user will have to re-login to the application.
- [...] We must plan for approx 20 simultaneous users, and perhaps 1000 non-expired sessions during peak hours.
Is the PDO pattern useful if we don’t use the Gateway pattern?
20 simultaneous users is not a huge number - but it is also important to know what they are doing :-). I would measure the memory consumption of 1000 sessions and then decide. jmeter is perfect for breaking a server.
A domain driven approach seems like a good idea regardless if we use the Gateway pattern. But the PDO pattern describes using JPA entities as the domain objects. Do you think this is suitable if we don’t use the Gateway? Do you have any thoughts on using detached PDOs?
PDO is the fastest and most efficient way to build applications. In the first iterations you will only develop domain objects. If the estimated memory consumption happens to be too high, you can still built the Service Facades, Services and DTOs on demand.
I start the development of non-trivial (>CRUD) applications with Gateway / PDOs and measure the performance and memory consumption continuously. In fact it is often a Hudson / Jenkins, which start the stress test as a night job.
Using PDOs in stateless environments is still beneficial, but the PDOs get detached between requests. You will still have to re-attach the entities and you will need order of magnitude more methods in Service Facades to realize the same functionality in a Stateless environment.
there is no doubt that stateless session beans scale better than stateful once. But (this important now), using a stateful approach is more natural and can be a best case for some business requirements. To design a conversation with short-living steps with a stateful session bean, even in a cluster environment, is possible. The reason for such a decision could be to store only completed and validated data (not every single conversation step). The alternative to such an approach is to use the HttpSession, which could lead to poor performance, due to frequent updates.
My impression is that application server vendors learned their lessons and improved the cluster behavior of stateful session beans (e.g. consider JBoss replication policies). A problem is surely the session timeout and the synchronization of the HttpSession and stateful session bean timeout, but this can be handled by configuration.
Stateful session beans are designed for the requirements of a conversation and can be synchronized with the transaction state by implementing the “SessionSynchronization” interface.
The passivation of stateful session beans and resource management seems to be better than in the past, so that depending on the business requirements the stateful approach may have benefits.
There is no general rule for the decision to use stateful or stateless session beans in the field, this decision depends on the business requirements (functional and non-functional) and the application server infrastructure.
At least, my opinion is that every application has to hold some state to minimize the effort to store the data for every single request and to reduce the garbage of not important request data in database. Therefore the HttpSession, brand new Flash in JSF 2 and stateful session beans are candidates to store temporary state during request processing.
Posted by Jörg Rückert on February 25, 2011 at 08:06 PM CET #
>"there is no doubt that stateless session beans scale better than stateful one"
This only doubtless in case the connection to the database and IO capabilities of the DBs are infinite.
>"Stateful session beans are designed for the requirements of a conversation and can be synchronized with the transaction state by implementing the “SessionSynchronization” interface.
The passivation of stateful session beans and resource management seems to be better than in the past, so that depending on the business requirements the stateful approach may have benefits."
BUT: why to replicate? The replicated state just cannot be consistent and scalable at the same time. If you don't distribute the state and not passivate your beans, in worst case the user will have to re-login or re-fill his shopping cart...
thanks for your feedback!,
Posted by adam-bien.com on February 25, 2011 at 08:22 PM CET #
What about the contained-managed security in EJB (i.e.: @RolesAllowed, etc)?
If I am not wrong, by using Gateway and Domain-driven design the user interface will have access to virtually all database via the PDO graph, so it will be difficult to make security restrictions on certain parts (tables, attributes) of the database.
Posted by lipido on April 05, 2011 at 08:47 PM CEST #
I'm also curious how you would use Gateway and Domain-Driven design in the presence of a database requiring different roles for different users.
Posted by torrulio on December 18, 2012 at 06:27 PM CET #