Oh...I think I broke a rule here.
> -----Original Message-----
> From: Louth, William (Exchange)
> Sent: Thursday, March 09, 2000 11:49 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Stateless bean for caching (Under certain conditions)
>
> 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 database 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: 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".
