CODEWITHSUNDEEP
javajakarta-eepersistence
Michael Wiles
Michael Wiles

Reputation: 21194

Scalable, low overhead, high performance java persistence framework

I am looking to build a web site/application. The class model is around 100 objects and is not particularly complicated.

The web site needs to be built to handle around 30 000 concurrent users but it should potentially be able to handle more.

I would like to use a ready made persistence framework rather than write my own jdbc for accessing the database.

I have no option but to use a relational database.

I would prefer it have some form of caching baked in and would also prefer to be able to customise the sql as this is often necessary for performance tuning.

Any suggestions for what persistence framework I should use?

UPDATE: Thanks everyone. I think the ability to hand code the sql is trumps in this case. You can do some concurrency tweaking if you have access to it. While I agree, you have access to it in hibernate/jpa as well, it's the exception not the rule. myBatis is also a lighter weight, less "magic" kind of persistence framework. Furthermore, for performance and scaling reasons I don't think it wise to use too many foreign keys where the collections are managed by the persistence framework, so I probably won't use that ability in hibernate anyway. This would allow me to shard the db if necessary. I also think that myBatis is probably an easier persistence framework to master first time up. AFAIK, it doesn't have transparent persistence for example. Your answers have confirmed that there isn't another persistence framework floating around that is more suited to these requirements.

Upvotes: 3

Views: 4125

Answers (6)

Vlad Mihalcea
Vlad Mihalcea

Reputation: 154190

Hibernate can be used as a high-performance data access library for the following reasons:

  • extended identifier generators (hi/lo, pooled, pooled-lo)
  • transparent prepared statement batching
  • entity-level cache highly consistent concurrency strategies
  • versionless optimistic locking (e.g. OptimisticLockType.ALL, OptimisticLockType.DIRTY)
  • support for multitenancy

Upvotes: 0

Lukas Eder
Lukas Eder

Reputation: 221370

I may be a bit late for your decision, but I think this might be an option for future considerations. I agree with Qwerky, that caching by the data abstraction layer (i.e. ORM or other framework) is overrated. Most modern RDBMS are very fast with their own internal caches, so usually performance-tuning is more of a DBA-job than a developer one. Besides, badly configured caches quickly turn into a performance nightmare.

I have created jOOQ as a database abstraction framework that tries to stay very close to SQL itself, without putting much more abstraction on top of JDBC apart from object-oriented typesafe queries built from a fluent API. jOOQ does not hide any relational facts from your Java code, so you have full control of the SQL used.

http://www.jooq.org

Upvotes: 3

mrG
mrG

Reputation: 1

what about persistence where rdbms is not required, a dedicated high-speed, high-reliability, and high-concurrency persistent store that is on the Collections class model? Oracle's (sleepycat) Berkeley DB was a very near fit but sadly runs into show-stopper locking problems with high-concurrency.

Upvotes: 0

Qwerky
Qwerky

Reputation: 18455

Worry about your infrastructure and avoid designing in bottlenecks, rather than the framework.

If you want to handle a lot of concurrent users then design to scale with hardware. Don't worry too much about caching data in your app, most decent databases do a good job of it for you, so long as you put enough memory in there.

Upvotes: 2

skaffman
skaffman

Reputation: 403601

If hand-optimised SQL is something you want, then I suggest myBatis (formerly known as iBatis). It handles the JDBC mechanics for you, as well as the object-column mapping, using hand-written SQL that you give it.

What it won't do for you is object-relational mapping (i.e. automatic handling of associations and collections). If that's more important for you, then a JPA implementation like EclipseLink or Hibernate is the obvious choice. These can also handle custom SQL, but it's a more fiddly than with myBatis.

Both should be able to handle your load requirements without issue - the question is can your database handle it.

Upvotes: 3

weltraumpirat
weltraumpirat

Reputation: 22604

The first and obvious choice would be the JPA, or Hibernate, from which it was derived.

Upvotes: 0

Related Questions