Hi dan
Have you thought about what happens with clustering assuming their is a need
for fail over saftely and load balancing. What I have would do, is to
consider the voltaility of the data and maybe keep a timestamp of the last
time we loaded from the database if this expires my property environment
setting then I will load again and set the timestamp thus this reduces the
amount of database loading while still given some degree of synching with
the daabase state.
For a singleton we would have to deploy one container of deploy this bean in
one of our clustered containers. The problem with the latter is that now we
will incurre extra overhead since clients connected to the container without
this bean will have to performance method calls across processes thus
reducing performance and creating a potential bottle neck.
kind regards
William
> -----Original Message-----
> From: dan benanav [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, February 29, 2000 11:43 AM
> To: [EMAIL PROTECTED]
> Subject: Stateless bean for caching (Under certain conditions)
>
> I know this has been discussed somewhat in this newgroup but I haven't
> seen any real conclusion on what I am going to suggest here.
>
> It seems to me that stateless beans can be a good choice for caching
> database data under certain circumstances. One great thing about a
> stateless bean is that they provide automatic failover in a clustered
> environment. Also stateless beans are not passivated. Here are the
> conditions under which I think stateless beans can be used for caching.
>
> 1. Going to the database on each call to get the data would be
> prohibitively expensive.
> 2. You are willing to have multiple copies of the cache around. Or if
> the server allows you to set the maximum number of beans then you could
> have a singleton.
> 3. The number of updates to the database is relatively small and it is
> easy to update the cache if the nature of the updates is known.
>
> The idea is that you would have multiple copies of the cache in each
> stateless bean created by the container. To implement this you would do
> the following.
>
> Each stateless bean maintains a sequence number. The database maintains
> a table which contains the latest updates. Whenever an update is made
> to the database which can affect the cache an entry should be made into
> that table. Each entry has a sequence number. When a call is made to
> the stateless bean it gets all the new updates from the database since
> it's last call and appropriately updates the cache.
>
> Imagine a case where no updates are made. Then this would certainly be
> very efficient.
>
> One question I have is whether most EJB servers allow you to specify how
> many stateless session beans are created. It still would work without
> that but it would be nice to be able to specify it. On a side note, if
> one could specify that at most one stateless bean should be created then
> wouldn't that provide a singleton? If that is the case then you could
> skip the update checking if you force all updates to go through the one
> stateless session bean.
>
> What do you think? Am I missing something here?
>
> Sidebar: Stateless Session Beans and singletons.
> It seems to me that if you can specify that at most one stateless bean
> should be created then you could create a singleton. This relies on the
> fact that the container will serialize calls to the stateless bean.
>
> dan
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
