-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 
Author Message
 Post subject: Write rarely Read often
PostPosted: Mon Oct 25, 2004 5:12 pm 
Newbie

Joined: Mon Oct 25, 2004 4:34 pm
Posts: 6
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:
Code:
s = HibernateUtil.currentSession();
tx = s.beginTransaction();
s.saveOrUpdate(blah);
tx.commit();
s.flush();


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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 25, 2004 7:27 pm 
Pro
Pro

Joined: Tue Aug 26, 2003 8:07 pm
Posts: 229
Location: Brisbane, Australia
Would using a 2nd-level cache, like EHCache work here?

_________________
Cheers,
Shorn.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 25, 2004 8:07 pm 
Newbie

Joined: Mon Oct 25, 2004 4:34 pm
Posts: 6
stolley wrote:
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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 25, 2004 8:14 pm 
Pro
Pro

Joined: Tue Aug 26, 2003 8:07 pm
Posts: 229
Location: Brisbane, Australia
(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?

_________________
Cheers,
Shorn.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 25, 2004 9:26 pm 
Newbie

Joined: Mon Oct 25, 2004 4:34 pm
Posts: 6
stolley wrote:
(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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Oct 25, 2004 9:31 pm 
Pro
Pro

Joined: Tue Aug 26, 2003 8:07 pm
Posts: 229
Location: Brisbane, Australia
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?

_________________
Cheers,
Shorn.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.