Is JPA + EJB very slow (or heavy) for online transactions?

Question

I am developing a standalone java client application that connects to a Glassfish v3 application for JPA / EJB facade style transactions. In other words, my client application does not connect directly to the database to CRUD, but migrates JPA objects using sessions without saving EJB state.

I have scenarios in which this client application will be used on an external network connected to a VPN via the Internet, with a client connection of 512 Kbps DSL, and a simple request takes so long, I see a traffic graph and when I merge the entity in the client application, I see a megabyte of traffic (I could not believe that the object of the purchase order could weigh more than 1 mb).

I have a LAZY sample in almost all many-to-many relationships, but I have many one-two-one relationships between entities (but this is a big advantage for JPA!).

Can I do something to speed up the transaction speed between the JPA / EJB server and the remote java client?

Thanks in advance.

Answer 1

How much data do you really translate? Perhaps there is a product in the purchase order that you submit that has a model, which has a supplier, which has a set of models ... and so on ...

You can try to serialize the object that you send to the server into a file (using the standard ObjectOutputStrem object) and check how large the file is.

Answer 2

I see a traffic graph and when I combine an object in the client application I see a megabyte of traffic (I could not believe how a purchase can be more than 1 MB).

RMI-IIOP is a little more verbose than regular RMI. In my experience, when moving large graphs it does not work.

Until now, I remember (but maybe everything changed in the meantime) when you transfer a lazy loaded object, parts that have not yet been loaded are sent as they are (the proxy is serialized), which means that you may not be able to access on the client, because lazy loading will not work if there is no more session. Do you look forward to downloading the object before sending it to the client?

Can I do something to speed up the transaction speed between the JPA / EJB server and the remote java client?

But the essence of the problem is that you are in a scenario where you need to think about a data transfer strategy. You must develop your application so that you do not send large charts; this problem should be solved in the design of your application. You can then decide to still send JPA objects or rely on a data transfer object (DTO).

You can also use the extended persistence context with a session with a bean state, so I think the client-side object can still be loaded lazy. But I never used it personally and I don’t know if it works well or not.

Answer 3

If I understand your architecture correctly, you:

Client(works with disconnected Entities) ----RMI/IIOP---> Server(SLSB, using entitiy manager, JPA persistence) ----JDBC-------> Database 

In essence, your SLSBs express their interface in terms of JPA objects, your DTOs are JPA objects. I see two possible scenarios:

• Your client only needs a subset of the data in your JPA objects, and you transfer more than you need. For example, you may need only the name of the employee, and you will send his entire life story.
• you cross more of the relationship tree than you intend

I feel that you must first determine exactly what you are getting in the client. It should be pretty easy to add some trace instructions to see exactly what data you have.

Perhaps by setting up lazy loading, etc. you can control the behavior.

My expectation is that you may need to define client-specific “subsets” of DTOs, and your SLSB acts more like a facade, sending only the subset data. This works more, but you have great control over what is in the interface.

Architecturally, fine-tuning the remote interface is quite a reasonable thing to do.

Answer 4

Can I do something to speed up the transaction speed between the JPA / EJB server and the remote java client?

You cannot speed everything up. However, you can transfer less (only the required part or lighter objects).