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".
