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

"Franklin, Benjamine" wrote:
>
> If I use entity bean ,if the bean is no longer used it will be removed from
> cache, but when I use stateless session & "static final " the cache keeps on
> growing which is unwanted.
>
> Also in my case the database may be updated or new records may be inserted
> directly to database, so If I use entity bean then I can set a timeout on
> entity bean that the bean should be refreshed after 30 minutes.
>
> Ben
>
> -----Original Message-----
> From:   Francis Pouatcha [mailto:[EMAIL PROTECTED]]
> Sent:   Monday, September 18, 2000 1:52 PM
> To:     [EMAIL PROTECTED]
> Subject:        Re: Entity bean design question
>
> Hi Benjamin,
>
> A nice way to implement a cache (that solves the concrete probleme you
> have) will be to use stateless session beans that all use the same
> "static final" data access object (DAO) to serve clients. Since your
> data don't need be "updated", you don't need entity beans or any
> concurency controll. Advantages of this approach are:
>         - Stateless session bean are pooled (not passivated), so the server
> will never unload your cache.
>         - Your Application remain portable (ejb forbids static fields but
> allows static final fields).
>         - The cache exist only once in each EJB-VM.
>         - Multithreated access (but unsafe: since concurent threads will
> load
> and cache the same row. But it doesn't count because of the readonly
> character of your application).
>
> /Francis
>
> Do the hole entitybean work into your cache.
> "Franklin, Benjamine" wrote:
> >
> > Hi ,
> >
> > I may be totally insane. Please correct me wherever I go wrong.
> >
> > This is my situation. In our web application, users enter tickers like
> IBM,
> > MSFT etc and ask for all the documents about those companies.
> >
> > My database table looks like
> >
> > doc_id  ticker  document_name
> > 1       IBM     jhgfg
> > 2       IBM     kjfhgdkf
> > 1       MSFT    jhgfg
> >
> > combination of doc_id and ticker is the primary key
> >
> > I'm planning to use Entity beans. The main thing and the only thing I
> expect
> > from the Container is caching, so that if one user requests documents for
> > IBM and once the IBM entity bean is created, for the next user it should
> not
> > go back to database, it should get from cache . I don't do any
> transaction.
> > My entity beans are readonly, I'm not using "create" in entity bean (since
> > this is done directly to database by some other process), the primary use
> of
> > my bean is for listing (in html pages).
> >
> > Let say I define
> >
> > DocumentEntityBean
> > {
> >   int doc_id;
> >   String ticker;
> >   String document_name;
> >
> >   findByTicker(Vector tickers)
> >   {
> >         sql = "select * from doc where ticker in (..)"
> >         //creating primary key from the data returned from database
> >   }
> > }
> >
> > and Primarkey is DocKey(int doc_id, String Ticker)
> >
> > If I use CMP, I think the default behaviour is ,
> >
> > when I call findByTicker(tickerVector), for finding the primary key a
> query
> > is executed , and then for each returned primary key,  lets say there is
> 50
> > primary keys returned, then another 50 queries are fired to the database,
> if
> > the entity beans for those primary keys are not available in cache.
> >
> > The above is my understanding, but I'm a beginner, may be I'm wrong, if
> > wrong please correct me.
> >
> > If the above is correct , then I want to optimize this
> >
> > My idea is
> >
> > Primarkey is DocKey(String Ticker)
> > the reason why I choose this is user needs document only based on tickers,
> > rather than doc_id, ticker
> > Also instead of creating an entity bean for each document, I have only one
> > entity bean for a ticker which has a vector of documents
> >
> > DocumentEntityBean
> > {
> >   String ticker;
> >   Vector Documents; //contains vector of Document object
> >
> >   findByPrimaryKey(pk)
> >   {
> >         sql = "select * from doc where ticker = pk.ticker"
> >         //execute sql
> >         //set ticket= pk.ticker
> >         //from result set create the Vector of Documents
> >         while(result.next())
> >         {
> >                 Documents.addElement(new
> > Document(result.getString(1),result.getString(2) ));
> >         }
> >   }
> >
> >   findByTicker(Vector tickers)
> >   {
> >         //without doing a query ,
> >         //create primary keys from from vector of tickers
> >         //in this way one query is avoided
> >         // like
> >         Vector result = new Vector;
> >         for(int i=0; i< tickers.size(); i++)
> >         {
> >                 result.addElement(new Dockey(tickers.elementAt(i)));
> >         }
> >         return result;
> >   }
> > }
> >
> > the above method reduces the number of queries to number of tickers. I
> feel
> > this is much better since it reduces number of queries from 50 to 3or4
> >
> > I want to still optimize this, I want to make only one query even if there
> > is multiple tickers
> > so I want to change the findByTicker() as below
> >
> >   findByTicker(Vector tickers)
> >   {
> >         //First check whether the entity beans for this tickers are
> > available in cache
> >         //I don't know whether there is EJB standard method to do this
> >
> >         //then separate out all the tickers which are not in cache
> >
> >         // do   sql = "select * from doc where ticker in ( not in cache
> > tickers )"
> >
> >         //get data from the result and load data into individual ejb beans
> >
> >         //so now the beans which are not available in cache are now
> > available
> >
> >         //return the primary keys created from vector of tickers , doing
> > like this will make the container not going back to database
> >
> >   }
> >
> > In the above method , I feel whatever the case only one query is fired.
> and
> > if the bean is in cache no query is fired.
> >
> > Am I going insane anywhere, or missing something, can you guys tell me
> what
> > will be the problems in this approach?
> >
> > Thanks
> > Ben
> >
> > This message is for the named person's use only.  It may contain
> > confidential, proprietary or legally privileged information.  No
> > confidentiality or privilege is waived or lost by any mistransmission.
> > If you receive this message in error, please immediately delete it and all
> > copies of it from your system, destroy any hard copies of it and notify
> the
> > sender.  You must not, directly or indirectly, use, disclose, distribute,
> > print, or copy any part of this message if you are not the intended
> > recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve
> > the right to monitor all e-mail communications through its networks.  Any
> > views expressed in this message are those of the individual sender, except
> > where the message states otherwise and the sender is authorised to state
> > them to be the views of any such entity.
> > Unless otherwise stated, any pricing information given in this message is
> > indicative only, is subject to change and does not constitute an offer to
> > deal at any price quoted.
> > Any reference to the terms of executed transactions should be treated as
> > preliminary only and subject to our formal written confirmation.
> >
> >
> ===========================================================================
> > 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".
>
> This message is for the named person's use only.  It may contain
> confidential, proprietary or legally privileged information.  No
> confidentiality or privilege is waived or lost by any mistransmission.
> If you receive this message in error, please immediately delete it and all
> copies of it from your system, destroy any hard copies of it and notify the
> sender.  You must not, directly or indirectly, use, disclose, distribute,
> print, or copy any part of this message if you are not the intended
> recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve
> the right to monitor all e-mail communications through its networks.  Any
> views expressed in this message are those of the individual sender, except
> where the message states otherwise and the sender is authorised to state
> them to be the views of any such entity.
> Unless otherwise stated, any pricing information given in this message is
> indicative only, is subject to change and does not constitute an offer to
> deal at any price quoted.
> Any reference to the terms of executed transactions should be treated as
> preliminary only and subject to our formal written confirmation.
>
> ===========================================================================
> 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".

Reply via email to