«

Hi,

I have database tables which translate into business objects with 20-30
fields, 5-10 child objects with again 20-30 fields.

50% of the fields are a long integer relatiing to a reference table.
In the object I have a display field which equates to the reference
table display.

Every time I pull an object out of the database I populate its
reference displays, making it very easy to present searches, populate
combo lists etc.

However there is a cost to populating the object with all the 150+
display values. If I am pulling out 50-100 objects from search
results, that is a lot of lookups.

Since I'm stubborn I refuse to entertain passing this workload on to
the database. I dont care how efficient their caching is - that is not
going to scale very well and it would be too complex to figure out
clustering on the database side as I am supporting at least one open
source database.

As an FYI this is running on JBoss under a stateless session bean, I do
use Hibernate for the data layer.

So what I did was I have a local stateless session bean which performs
the 'reference lookup'. Every time it does it, it pops the display and
the id into a hashtable for next time. In fact in some cases it pops
an entire business object into the hash.

I wondered if the old Hashtable was really the right thing for this.
It works, though obviously there is a danger that the cache would need
purging to remain efficient and not hog too much memory. While I have
a first pass at synchronizing the code, it probably needs more work to
be more efficient.

I also do this on the client - where it really helps as the client does
not ask for business objects in the first place if they are cached
locally. Of course when the client restarts that is lost.

I considered caching the reference locally on the client. Obviously a
lot of extra work to prevent stale data.

Any other ideas on how to improve this?

thanks

Timasmith wrote:
> Hi,
>
> I have database tables which translate into business objects with 20-30
> fields, 5-10 child objects with again 20-30 fields.
>
> 50% of the fields are a long integer relatiing to a reference table.
> In the object I have a display field which equates to the reference
> table display.
>
> Every time I pull an object out of the database I populate its
> reference displays, making it very easy to present searches, populate
> combo lists etc.
>
> However there is a cost to populating the object with all the 150+
> display values. If I am pulling out 50-100 objects from search
> results, that is a lot of lookups.
>
> Since I'm stubborn I refuse to entertain passing this workload on to
> the database. I dont care how efficient their caching is - that is not
> going to scale very well and it would be too complex to figure out
> clustering on the database side as I am supporting at least one open
> source database.
>
> As an FYI this is running on JBoss under a stateless session bean, I do
> use Hibernate for the data layer.
>
> So what I did was I have a local stateless session bean which performs
> the 'reference lookup'. Every time it does it, it pops the display and
> the id into a hashtable for next time. In fact in some cases it pops
> an entire business object into the hash.
>
> I wondered if the old Hashtable was really the right thing for this.
> It works, though obviously there is a danger that the cache would need
> purging to remain efficient and not hog too much memory. While I have
> a first pass at synchronizing the code, it probably needs more work to
> be more efficient.
>
> I also do this on the client - where it really helps as the client does
> not ask for business objects in the first place if they are cached
> locally. Of course when the client restarts that is lost.
>
> I considered caching the reference locally on the client. Obviously a
> lot of extra work to prevent stale data.
>
> Any other ideas on how to improve this?
>
> thanks

There are built in caching mechanisms for Hibernate, I wouldn't try to
invent your own.
If you don't need all of the data all of the time, you might try using
lazy-loading.