Francis,
Actually, I wrote a fairly long posting on this topic a few weeks back.
In summary, I discussed the fact that the memory requirements for SLSBs
and EJB 1.1 CMP beans is equivalent. I also showed that the memory
requirements for EJB 2.0 CMP beans is significantly less than either
SLSBs or EJB 1.1 CMP beans, due to the ability for the container to
implement "copy-on-write". Please see my previous posting for details.
As to your other issue of needing to write EJBs which will run efficiently
on any container, this is a much harder nut to crack.
-jkw
Francis Pouatcha wrote:
>
> Hi Jonathan,
>
> 1. I'm speaking about writting portable bean. I can't presume optimistic
> or pessimistic locking when writting a bean.
>
> 2. Even if we assume the container is using optimistic locking, how
> would you implement it to solve the caching problem presented below?
> - Will you use multiple copies of the same entity bean instance into
> the same VM? This even will not automaticaly shorten the response time
> (the full memory also makes the VM slower).
> - Will you leave multiple thread concurently run into the entity bean?
> I don't belive, unless you require the entity bean programmer to use the
> synchronized keyword.
>
> So I belive entity beans with optimistic locking only solve the
> concurency problem to some extent. There are cases where they don't
> help.
>
> I will vote for optimistic locking when the bean instance doesn't carry
> a lot of data. That is not the case for Benjamin, he is trying to
> implement a readonly like cache (with time to time update).
>
> /Francis
>
> Jonathan Weedon wrote:
> >
> > Francis,
> >
> > <vendor>
> >
> > I was curious about your statement:
> >
> > you will have a great delay due to the locking of the EB
> >
> > What locking are you talking about? Some containers implement
> > pessimistic locking (for example, WebLogic) in which case locking
> > can be a significant performance issue. However, some containers
> > implement optimistic locking (for example, IAS) in which case there
> > is no such locking by the container. Of course, you still need to
> > look at the locking model of the DBMS, but again you have choices
> > here, and using a database which supports optimistic locking would
> > avoid such performance problems.
> >
> > Or did I miss the point?
> >
> > </vendor>
> >
> > -jkw
> >
> > Francis Pouatcha wrote:
> > >
> > > Hi Ben,
> > >
> > > Entity beans (EB) are not appropriate for the purpose you depicted
> > > bellow. Because of the intensive concurent acces to the Bean, you will
> > > have a great delay due to the locking of the EB. It is beter to
> > > implement it like a read only like cache. Also loading and unloading EB
> > > isn't deterministic, these operations depend on how the server is
> > > implemented (an EB wich is realy hited will even never be unlaoded).
> > > Setting timeout on entity bean isn't specified. If you do it, your bean
> > > won't be portable.
> > > If your DB get updated from time to time, I see two portable sollutions
> > > for updating the cache:
> > > -UpdaterBean (Entity) using a timer service (i.e. over JMS) that triger
> > > the bean to update the cache every 30 min.
> > > - Simply use System.currentTimeMillisec() from inner the cache to
> > > measure the age of your cache and update it when needed, but this will
> > > only be done when a request is sent to the bean since the bean can't
> > > triger itself.
> > >
> > > /Francis
> >
> > ===========================================================================
> > 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".
>
> --
> [EMAIL PROTECTED]
>
> MATHEMA Software GmbH
> N�gelsbachstra�e 25 b
> 91052 E r l a n g e n
> D e u t s c h l a n d
> Tel +49(0)9131/8903-0
> Fax +49(0)9131/8903-55
> http://www.mathema.de
>
> ===========================================================================
> 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".
===========================================================================
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".
