Cached entity bean data is nice....but we want more
gorano Sep 2, 2003 6:02 PMOur development team are creating a new routing system for instant messaging, all on JBoss 3.2.2.
The expected volumes are quite high, but during short periods (5-30 minutes tvice a day) we can expect an extremly high volume.
One of the requirements is that we can deliver the messages from point A to point B,C,D... very fast without delays during the peaks.
Point A is a remote application acting as a receiver of messages, pushing the messages onto a JMS-queue to achive an asynchronous behavior.
Point B, C and D are different URLs expecting HTTP-requests.
We are running a prototype today using message driven beans as consumers. The MDB makes the request over a short lived socket connection (fast response time).
Now to our potential problems (discussions and recommendations are highly appriciated):
To be able to route the message correctly we have a quite expensiv data look-up process to do, involving many entity beans and relationships between them.
The data are highly static so one solution would be to cache the result from the look-up, using 'read only' and 'commit option A' on involved entity beans.
How fast and efficient is this container cache? Are we better of implementing our own cache functionality in a session bean, just storing the data object in a map?
Next problem is a bit more complex and have to do with the logging of data produced for each message.
We would like an asynchronous logging to be put in place, i.e asyncronous insertions into our database.
The reason for this is the fact that the database insertions comes with a cost and we don't want to see this as a bottleneck during the message peak mentioned earlier.
One solution could be to push the data to be logged on to another JMS-queue and let MDBs do the logging in their own speed in the background. What cost will this approach have? The queue is persistent, i.e producing insertions into the Jboss db. We do believe that this cost would be smaller than a synchronous logging into many tables. right/wrong?
Is there another way of asynchronous logging. Can we have newly created entity beans to wait and save the data in the backround in an asynchronous fashion without the JMS-queue?
Ok a power-cut would mean lost data (something that the j2ee-spec addresses quite well). But what if we feel that we could live with a potential data-loss under exreme circumstances (we can always use power-backup that could keep the hardware going).
Can we in one way or another just store the log-data in memory and have a background process to do the insertions, or is this violating the whole idea behind J2EE?
Thanks for your time
Goran
By using
<>