T
Timasmith
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
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