Hi,
> " It is a very common
> design pattern that early in the life of a SFSB data is retrieved from a
> database, during its life the data is updated, and at the end of its life
the
> data is written back to the database (or not, depending on the outcome of
the
> client session)."
In the scenario that was mentioned, the data has to be updated to
database on user request since every request is a transaction and there's
no conversational state. So there's no option of updating the data in the
bean and at the end of its life write data back to the database. What you
have suggested is okay in the scenarios like shopping cart where even if the
bean crashes , data integrity of your database is not lost.
Here SFSB is used only as a cache and nothing more. If the data were
not user specific, we would have gone for an entity bean. So the question is
SFSB can be used as a user specific data cache or not? Or is there any
better alternative?
Thanks
Sandhya
Sandhya S Suku
MphasiS BFL Limited, Bangalore - 560076.
91-80-5522713 Ext. 2169
----- Original Message -----
From: Ian McCallion <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 08, 2001 9:47 PM
Subject: Re: Using Stateful Session Bean to cache client specificdata
indatabase
> "Padmanabhan.K" wrote:
> >
> > I require to cache some client specific data in the
> > application to avoid frequent database hits. Can I use
> > stateful session beans for caching purposes,
>
> Yes.
>
> > ruling
> > out the choice of Entity beans assuming it is more
> > intuitive only for caching any client independent data
> > in Entity Beans. Am I right here? Also, I am aware
> > that Stateful Beans are generally used for holding
> > client conversational states and clearly my case is
> > not that. Also would like to discuss any better
> > alternatives for my problem.
>
> A SFSB is probably quite appropriate for your application. It is a very
common
> design pattern that early in the life of a SFSB data is retrieved from a
> database, during its life the data is updated, and at the end of its life
the
> data is written back to the database (or not, depending on the outcome of
the
> client session).
>
> Ian McCallion
> Alexis Systems Limited
> Romsey, UK
>
>
===========================================================================
> 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".
