Can Stateful Java EE 6 Apps Scale? - Another Question Of The Week 📎
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.