I have objects which are rather slim. I'd like to add context details from database tables that flesh out the messages and give them context for the local viewer. I'm expecting to process thousands of these objects per second. Would it be appropriate to use hibernate as the mechanism to retrieve the context details from the database?

My happy thoughts are:
I don't like writing SQL.
I'd rather deal in objects.
I like the idea of using something with built in caching.

My sad thoughts are:
Slow.
I don't really understand proper session/transaction management in threaded J2SE apps.
I have no need of transaction support. The database is just a place to store the details that flesh out my messages.

So, while I don't expect anyone to tell me what to do, I'd appreciate opinions based on your use of hibernate.


I don't have any code, so no bugs, no logs, no stacktraces, no snippets of code.

Hibernate version:
most current

That sounds like most of the things you'd be retrieving from the DB would be static messages from static tables: a way of converting error codes and suchlike into useful messages. If that's a big part of what you're expecting to use hibernate for, then there is more likely to be a performance gain than performance loss if you use hibernate, especially if you take the trouble to profile cache hits and tune it accordingly.

If you're expecting to search for hundreds of "real" objects (ones whose values are not constant, and might be updated after you retrieve them), thousands of times a second, then there will most definitely be a performance hit using any ORM, including hibernate.

Well, its fairly static values, but a lot of them.

Error messages is close enough. So, imagine you've got about a half million error codes with corresponding messages. When we have an error, it tends to appear 50 times in row, then go away for a while. I expect caching to help a lot because of that pattern.

Now, yeah, I'd just put this in memory if it was this situation, but my error messages are big.

They'll end up in memory anyway, because of caching. The good thing is, that the cache uses Weak- and Soft- references, LRU/MRU ordering, and other things that ensure that the least valuable cache entries are thrown away before the ones that you need the most. So it's very efficient.

You may want to do some tweaking to cache some queries (the error message kind of queries) in a separate bit of the cache; by default, cached things "disappear" when a session is closed, and you don't want to leave sessions around for too long. But hibernate is able to put cached items in different parts of the cache, so you can put cached rows of immutable tables into a bit of the cache that every session can access. It's fiddly, but it will help your performance even more.

Fantastic.

Now you've mentioned sessions. Here's where I start asking the questions that lead to a RTFM...but I'll toss one out.

Is there a session/transaction strategy that would be best for this model?

In some unit tests I've messed with just to get a feel for things, I created a single transaction, then within a tight loop did a findByName on a table PK and was able to grab about 60K objects/sec. Not bad eh? But, if I start following the JDBC like model from the "Sessions and transactions" I wind up with a performance rate closer to 500/sec, which isn't really impressive. The main code difference here being that the beginTransaction and commit calls are now in the loop and are run each time.

My intuition here is that since I'm creating a new session and transaction for each time through the loop I'm actually killing the first level cache...meaning I'm forcing a fresh query and object creation for each fetch.

Now, using one session/transaction for a long time seems wrong to me. A nice compromise might be to keep a session object in my lookupAgent and just create a transaction each time through, but that gets me errors (will take me a bit to get that error if this is important, I killed that code).

I guess, if you can point at someplace using a session/transaction pattern appropriate for me, I'll be a happy man.

First question would have to be: why transactions? They're not useful for read-only access. The purpose of a transaction is to ensure that non-atomic updates are performed atomically. If you're doing 60k reads and 0 writes, don't bother with a transaction.

Session strategies should almost always be "treat it like a hot potato": throw it away before it burns your hand. The one exception (to my mind) would be exactly what you're describing: purely read-only access on strictly immutable data. So long as you don't mind hogging a JDBC connection, then there's no real reason to get rid of the session. Use a separate session for your read-write access, and close it after every (short) transaction.

I don't agree with anything you wrote here.

(1) Always use transactions.
(2) The best scope of a session is "conversation" ... see Seam docs if you don't understand
(3) Sessions do not hog a JDBC connection
(4) Never share sessions between multiple threads or multiple conversations

To trobison: stop paying attention to microbenchmarks, they will ALWAYS lead you wrong! Don't preoptimize. Follow the standard recommended ways of doing things, and optimize actual working application code that causes a problem in production. Don't tie yourself in knots to eek tiny gains out of silly microbenchmarks that will never ever be noticed in a production system.

This is the best pattern known to man:

http://docs.jboss.com/seam/reference/en/html/configuration.html#d0e3005

I think I have more reading to do. I appreciate the thoughts.

Is it uncool to defend myself against Gavin? Heh.

1) In purely read-only situations, there is no reason to bother with transactions. There's no reason not to, either, but that doesn't detract from my point. I guess we'll have to disagree on this point.
2) I agree. Perhaps there's a difference in our understanding of the hot potato analogy. We're not disagreeing on this one :)
3) They do for me, and I forget that some people don't use homegrown connection/transaction providers. Never having used hibernate's own connection/transaction stuff, I'm not at all familiar with how or when sessions use their connections.
4) I didn't realize that I'd suggested that a session should be shared between threads, I certainly didn't mean to. As to sharing a session between conversations: I agree, but providing access to a load of immutable data can quite reasonably be argued to be a single, very long conversation. When the conversation stops, close the session.

I agree with the benchmarking comments.

Still reading docs...

However, I defend my performance wags. I'm trying to determine whether Hibernate is an appropriate tool for me to use. I have performance standards to meet and only so much of my application's execution time can be spent in database IO. I can't simplify the application or skip features in order to allow Hibernate to be used, it has to be the right tool for the job.

I do understand the problem of premature optimization, but I don't think that was the direction I was headed.

My real purpose here is trying to figure out whether it makes sense to use Hibernate in my case or whether I just need to find a object cache to keep me from hitting the database every lookup.

Again, thanks for the input guys.