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.  [ 2 posts ] 
Author Message
 Post subject: Caching whole lookup table in HashMap efficiently
PostPosted: Tue May 22, 2007 6:32 am 

Joined: Tue May 22, 2007 5:51 am
Posts: 2
I have one HUGE (legacy) lookup table that consists of say three columns (a, b, c) where a and b are the lookup key and c is the desired value. Columns a,b are not a primary key, so that for any a,b a set of many c's may be returned.

Without Hibernate (in non-JEE) I read this whole table with one select, create an instance of an Entry class per line and put this entry into a HashMap (hashCode/equals overridden so that it uses a and b). So I once initialize the map with one (complicated, long running) select, fetch all the rows it returns, put them into the HashMap (ArrayLists for multiple c's as values) and after that do *many* lookups with maximum speed by

ArrayList<C> lookupValues=hashMap.get(buildKey(a, b)).

Now I'm looking for a way to realize this in Hibernate efficiently. Basically this is a question about performance, as I found many (less efficient) ways to retrieve the data so far.

Things evaluated so far:

1) Composite Pattern (like in http://www.researchkitchen.co.uk/blog/archives/57): Mapping a base class for columns a and b, and a derived class for a,b,c. The method getChildren() returns the c's. This is fine, because one can map two classes onto the existing legacy table. Problem: Many selects. Would be a great solution if one could instantiate all objects immediately with just one select.

2) Queries: A simple createQuery("from Entries") would return everything as needed in one select, and would be cached as such (result cache). But in fact I need a createQuery("from Entries where a=:a and b=:b") for *lots* of a/b combinations, *without* Hibernate generating a separate select for each combination. Every single a/b combination is accessed just once, so the result cache does not help much.

3) More or less without Hibernate: Stateless Session Bean that holds a HashMap like in non-JEE-solution. HashMap initialized e.g. in @PostConstruct by iterating over result of createQuery("from Entries"). Then limit the pool size of that bean to 1 (to avoid redundant HashMap creation/initialization).

I wonder how one could use Hibernates second-level cache. Because basically it is some kind of HashMap, so if I could manage to get every row from the select into the second-level cache and access that by a given (a,b)-key, that could be the solution. (Problem: It's not a lookup by primary key, because a,b isn't unique.)

Sole requirement is speed, as tables are so large and number of lookups is great.

Any ideas are greatly appreciated!

 Post subject: Try UserTypes
PostPosted: Tue Nov 11, 2008 1:27 am 

Joined: Fri Oct 24, 2008 7:02 pm
Posts: 4
I have basically the same situation. I've thus far tried using Hibernate's L2 caching systems, but don't quite see the right way to handle it.

Check out UserTypes, this might be the way to go.

You would then not need to do a join, but can still do the O(1) in memory lookup.



Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 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.