JPA/ORM vs JDBC for performance limited machines

We are creating a small application that will be deployed to very limited machines. They have only 256mb of RAM.

I would like to use JPA as it simplifies the code and removes the need for JDBC ResultSet code. However, will the overhead of JPA on such small machi开发者_如何学JAVAnes be a factor? I am thinking of using Toplink at the moment, which comes in a 2.5mb JAR file.

We only have a limited number of tables, so the JDBC code won't be too much trouble. But JPA makes the code so nice.

Cheers.

---

JPA/ORM performance at runtime will always be greater than or equal to JDBC, since they're both based on JDBC.

As you've noted, the big lift you get from JPA/ORM is at development time.

I would like to use JPA as it simplifies the code and removes the need for JDBC ResultSet code.

I'm not sure that I understand this statement. JPA will be using a ResultSet behind the scenes; you just won't be writing it. The mapping from ResultSet to objects is encapsulated in XML or annotations.

If you're truly memory bound, you might have to pass on JPA and hand code the JDBC.

You might look at Spring JDBC in that case, because it's got a very nice design for JDBC support that makes it pretty simple.

256MB of RAM? You'll have a hard time using any 3rd party libraries.

---

Depending on the OS and what else you are running 256MB of RAM is not as small as you would think. It may be entirely feasible to use an ORM solution but the best way is to test and see for yourself.

It should be relatively simple to test this out and see if its going to work in your environment. Create a simple project or modification to your project that uses ORM, and a single entity to do some test transactions. Then watch how it performs and what the memory usage is like. Depending on what you need to do, it may be fine.

You can also cap the JVM memory to a certain level too, which will cause more garbage collections but it should prevent a crash unless you hit the limit.