I've worked through the examples and have got a decent mapping up and running. The problem that I'm running into is when I try to write my own cache.

The situation:
I've got a data object that is accessed several thousand times a minute, but is updated only once every minute or so through a JMS message. The access is through servelets, so both reads and writes are via separate threads.

What I'm currently doing:
I wrote my own cache, that opens up a session, gets all objects of the type, and closes it. then it hands the objects out upon request.

The various readers (through the servlet) do not access the DB, but merely increments an access counter (not persisted) on the object.

The writers (through the onMessage function of the JMS client) gets the object from the cache, updates the object based upon the JMS cache and the access counter, and saves it.

The problem:
If the writer is coded like:


then I get stale object exceptions eventually. If I add a s.close(); then everything is fine and dandy. The problem is that I'd like to avoid the call to close, as eventually I'll have a couple hundred of these objects, and close (and the ensuing open) seems to be pretty expensive.

Two questions:
1) Is there something inherently wrong in having Transient objects that aren't really transient? (it really is persistent, but it's not associated with any session.)
2) Does automatic versioning take care of this problem? I read through the documentation and it doesn't seem to address the issue of transient objects and associations with several threads...

thanks for any help.

Jeff

Would using a 2nd-level cache, like EHCache work here?

Unfortunately, no. I am actually looking for constant time access to the object based on several criteria. Think of a customer being accessed by customer ID, or Soc. Sec. #, or by First+Last name. That doesn't seem to be possible with a 2nd level cache.

Jeff

(These questions are really for my own understanding of 2nd-level caching, I have never done anything except play with the 2nd-level cache).

But, if you did the "Access by Customer ID" or "access by Soc. Sec. #" as HQL queries and marked the queries as cacheable, they'd be in the query cache, thus after the first lookup, accessing it'd be a relatively constant time (relative to DB access on a growing table). Then using the object itself would just be a lookup in the object cache.


Or am I missing something about the way 2nd-level caching works in HB?

From the query cache doc (14.5):
"This is only useful for queries that are run frequently with the same parameters"

The parameters are not the same. so we can't cache the result set.

Jeff

But then, won't you have the exact same issue with your own custom-written cache?

I thought that statment was just about the effectiveness of caching things generally, not about a specific limitation of Hibernate's caching architecture?