Re: To store a huge table during start-up of a J2EE application


Ravi Shankar Nair wrote:
Dear Rhino,

I agree, the table is small as per your thoughts. Though for us, it is abig
table.

Yah, basically it is alook up kind of data. FOr example the role
categories, the function ids, the action ids etc for a particular user. When
the user logs in, we need to check the entitlement, whether this user is
permitted to go for this function or not. Thats why we are caching it. Our
priority is not for memory concumption, but execution time. Thats why we
cant have a look up from servlet through an EJB or DAO kind of thing.

Any thoughts to share with? After contemplating a bit, what I am thinking is
this:- Assume that first four columns, col1...col4 are primary keys out of
the total 12 columns. My search or lookup is always based on the primary
key, i.e the first four columns. So I will have the startup init method in
one of the servlets, where I will create two strings. First one is
"col1__col2__col3__col4" (lets say the key)and second one is
"col5:col6:col7:col8:...col12" (lets say the value).Then I will populate a
hashtable with key and value.

Whenever a search is needed, I would first construct the key and look for
it.Once I get the value, I will STringTokenize it and use it wherever
required.

In case I need a search for only col1( may be in future), I would have
another hashtable to maintain col1_...col4.

Is this fine? Please comment. Thanks

The first thing to do is to create an Object that encapsulates these 12
columns i.e. attributes of that row.

Second this is (assuming for a second that your keying col1...col4 key
is good enough), store the "object" that you created in the previous
step as value of the hashtable - dont get into the business of
stringtokenizing etc, they are costly and round-about way of doing the
things at hand.

Now to your actual problem, if your primary keys and index are setup
correctly, a database query should not run for more than tens of
milliseconds - granted that there are some exceptions too. Since you
seem to indicate user-specific data, dont see the value of losing the
ability to do SQL like queries in return for 10 millis of time. And
actually, when you scale up with number of users, the memory will kinda
get abused, but the database can easily scale up to a high concurrent
query load.

--
Arvind

.

Relevant Pages

  • Re: Why is VARCHAR2(4000) bad ?
    ... Since we dont know in advance the size we will really need in the ... Aren't VARCHAR2 supposed to have a first byte to tell the string ... not have the options of variable length strings. ... This will minimize risk. ...
    (comp.databases.oracle.server)
  • RE: question of performance
    ... I've always wondered why *anyone* would recommend using strings as primary ... I realize they can make primary keys more "readable" if built up like ... If you're comparing millions of keys to build a ... compared in one CMP operation (one op to move the base integer to a register, ...
    (microsoft.public.access.queries)
  • Re: Does Codds view of a relational database differ from that ofDate&Darwin?[M.Gittens]
    ... > Marshall Spight wrote: ... > you to define certains sets of strings described by regular expression ... > as strings, and is user-extensible. ... > Another small thing is updating primary keys. ...
    (comp.databases.theory)
  • Elixer strings
    ... I dont think the coating stands up to acids very well, ... strings off...) ... good indication that Lemon Oil is NOT good for Elixer strings. ...
    (alt.guitar)