You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Bill Lear <ra...@zopyra.com> on 2003/03/07 00:41:44 UTC
Request persistence
I'm starting to learn Tapestry, and I would like to know how to make a
variable persist through requests, but not be serialized to disk
(possibly) along with the Engine, as described in Chapter 4, "Tapestry
Pages" of the Developer's Guide.
I have tried searching the Developer's Guide and the mailing list
archives, and have found nothing on this, though it's possible I'm
just missing due to vocabulary mismatch.
One method I have found that I think works is to make the variable
static; this, I assume, makes it shared among all instances of the
page, which is actually what I want. Not sure if this is the proper
way to do it, though.
What I am trying to do is to create a fairly large in-memory data
structure that persists across requests and that I can create lazily
by checking the value and restoring from disk or net if needed; so, I
don't want it serialized with the Engine.
Second question: What would I do if I wanted to do the same thing, but
not have it shared by all page instances? That is, have it be session
information that is somehow marked as "Don't worry about persisting
this to permanent storage for me, thank you, I'll take care of that
myself, in my own particular ... idiom".
One final thing: if making the variable static is appropriate for
sharing a variable, do I need to synchronize access to the method
that initializes it? So, let's say I have a page:
public class Home extends BasePage {
private static List birthdayList;
public List getBirthdayList() {
if (birthdayList == null) {
initBirthdayList();
}
return birthdayList;
}
private synchronized void initBirthdayList() {
// initialize from disk, net, whatever...
}
// ...
}
is that appropriate?
Any help much appreciated, as is the work already put into this
framework!
Bill
RE: Request persistence
Posted by Viktor Szathmary <ph...@imapmail.org>.
hi,
On Fri, 7 Mar 2003 14:35:56 -0600, "Bill Lear" <ra...@zopyra.com> said:
> On Friday, March 7, 2003 at 14:01:28 (-0500) Viktor Szathmary writes:
> >hi,
> >
> >> > What I am trying to do is to create a fairly large in-memory
> >> > data structure that persists across requests and that I can
> >> > create lazily by checking the value and restoring from disk
> >> > or net if needed; so, I don't want it serialized with the Engine.
> >
> >you could add a transient property to the Visit let's say, eg:
>
> Hmm, this seems vastly easier than manipulating the ServletContext.
> Forgive my ignorance, but how does one ensure that if the page is
> served to multiple persons at the same time, that one and only one
> of them initializes the variable? Would it be simply to make getFoo()
> synchronized?
i thought one of the questions was how do you have something session
specific that only gets retained in the VM locally.
if you wish to use a VM level instance, then the answer is a singleton,
or using a the servletContext(). initialization should be synchronized.
the object doesnt' even have to be serializable.
viktor
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
RE: Request persistence
Posted by Tarun Ramakrishna Elankath <ta...@webkadai.com>.
Will this solution work the way you intend it to do? The Visit object
has far as I know is specific to a client's session. The Visit object is
stored within the engine, which is an attribute of the http session.
(User Guide)
I guess the only real way is to mess about with servlet context after
all. I guess you could use the singleton pattern to do the job.
Regards,
Tarun
On Sat, 2003-03-08 at 02:05, Bill Lear wrote:
> On Friday, March 7, 2003 at 14:01:28 (-0500) Viktor Szathmary writes:
> >hi,
> >
> >> > What I am trying to do is to create a fairly large in-memory
> >> > data structure that persists across requests and that I can
> >> > create lazily by checking the value and restoring from disk
> >> > or net if needed; so, I don't want it serialized with the Engine.
> >
> >you could add a transient property to the Visit let's say, eg:
> >
> >class Visit implements Serializable {
> > private transient Object foo;
> >
> > public void getFoo() {
> > if (foo==null) {
> > // load/generate foo
> > }
> > return foo;
> > }
> >
> >}
> >
> >this way it will not be serialized across servers, but will be kept with
> >the session.
>
> Hmm, this seems vastly easier than manipulating the ServletContext.
> Forgive my ignorance, but how does one ensure that if the page is
> served to multiple persons at the same time, that one and only one
> of them initializes the variable? Would it be simply to make getFoo()
> synchronized?
>
> Thanks for the tip, Viktor.
>
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
RE: Request persistence
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
Pages are pooled. A page will be checked out of the pool just for the
duration of a request. There may be any number of page instances. There is
no guarantee that subsequent requests from the same client will utilize the
same page instance.
Visit object is unique to a single client; unless your application utilized
frames, it is unlikely you will be accessing it from more than one thread.
Adding synchronized is still a good idea.
ServletContext is a place to store resources needed by all sessions; for
example, a pooled database connection.
Visit is place to store resources needed by a single session; for example,
user authentication information, such as user's primary key in a database.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: Bill Lear [mailto:rael@zopyra.com]
> Sent: Friday, March 07, 2003 3:36 PM
> To: Tapestry users
> Subject: RE: Request persistence
>
>
> On Friday, March 7, 2003 at 14:01:28 (-0500) Viktor Szathmary writes:
> >hi,
> >
> >> > What I am trying to do is to create a fairly large in-memory
> >> > data structure that persists across requests and that I can
> >> > create lazily by checking the value and restoring from disk
> >> > or net if needed; so, I don't want it serialized with the Engine.
> >
> >you could add a transient property to the Visit let's say, eg:
> >
> >class Visit implements Serializable {
> > private transient Object foo;
> >
> > public void getFoo() {
> > if (foo==null) {
> > // load/generate foo
> > }
> > return foo;
> > }
> >
> >}
> >
> >this way it will not be serialized across servers, but will be kept
> >with the session.
>
> Hmm, this seems vastly easier than manipulating the
> ServletContext. Forgive my ignorance, but how does one ensure
> that if the page is served to multiple persons at the same
> time, that one and only one of them initializes the variable?
> Would it be simply to make getFoo() synchronized?
>
> Thanks for the tip, Viktor.
>
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
RE: Request persistence
Posted by Bill Lear <ra...@zopyra.com>.
On Friday, March 7, 2003 at 14:01:28 (-0500) Viktor Szathmary writes:
>hi,
>
>> > What I am trying to do is to create a fairly large in-memory
>> > data structure that persists across requests and that I can
>> > create lazily by checking the value and restoring from disk
>> > or net if needed; so, I don't want it serialized with the Engine.
>
>you could add a transient property to the Visit let's say, eg:
>
>class Visit implements Serializable {
> private transient Object foo;
>
> public void getFoo() {
> if (foo==null) {
> // load/generate foo
> }
> return foo;
> }
>
>}
>
>this way it will not be serialized across servers, but will be kept with
>the session.
Hmm, this seems vastly easier than manipulating the ServletContext.
Forgive my ignorance, but how does one ensure that if the page is
served to multiple persons at the same time, that one and only one
of them initializes the variable? Would it be simply to make getFoo()
synchronized?
Thanks for the tip, Viktor.
Bill
RE: Request persistence
Posted by Viktor Szathmary <ph...@imapmail.org>.
hi,
> > What I am trying to do is to create a fairly large in-memory
> > data structure that persists across requests and that I can
> > create lazily by checking the value and restoring from disk
> > or net if needed; so, I don't want it serialized with the Engine.
you could add a transient property to the Visit let's say, eg:
class Visit implements Serializable {
private transient Object foo;
public void getFoo() {
if (foo==null) {
// load/generate foo
}
return foo;
}
}
this way it will not be serialized across servers, but will be kept with
the session.
viktor
--
http://www.fastmail.fm - Accessible with your email software
or over the web
RE: Request persistence
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
You can work through the Tapestry API to get to the Servlet API. Data such
as you describe should be stored as a ServletContext attribute. Such
attributes are shared by all sessions within the webapp, but not serialized
or replicated in a cluster. Tapestry uses ServletContext attributes for
much shared data (say, all the shared specifications and templates).
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: Bill Lear [mailto:rael@zopyra.com]
> Sent: Thursday, March 06, 2003 6:42 PM
> To: tapestry-user@jakarta.apache.org
> Subject: Request persistence
>
>
> I'm starting to learn Tapestry, and I would like to know how
> to make a variable persist through requests, but not be
> serialized to disk
> (possibly) along with the Engine, as described in Chapter 4,
> "Tapestry Pages" of the Developer's Guide.
>
> I have tried searching the Developer's Guide and the mailing
> list archives, and have found nothing on this, though it's
> possible I'm just missing due to vocabulary mismatch.
>
> One method I have found that I think works is to make the
> variable static; this, I assume, makes it shared among all
> instances of the page, which is actually what I want. Not
> sure if this is the proper way to do it, though.
>
> What I am trying to do is to create a fairly large in-memory
> data structure that persists across requests and that I can
> create lazily by checking the value and restoring from disk
> or net if needed; so, I don't want it serialized with the Engine.
>
> Second question: What would I do if I wanted to do the same
> thing, but not have it shared by all page instances? That
> is, have it be session information that is somehow marked as
> "Don't worry about persisting this to permanent storage for
> me, thank you, I'll take care of that myself, in my own
> particular ... idiom".
>
> One final thing: if making the variable static is appropriate
> for sharing a variable, do I need to synchronize access to
> the method that initializes it? So, let's say I have a page:
>
> public class Home extends BasePage {
> private static List birthdayList;
>
> public List getBirthdayList() {
> if (birthdayList == null) {
> initBirthdayList();
> }
> return birthdayList;
> }
>
> private synchronized void initBirthdayList() {
> // initialize from disk, net, whatever...
> }
> // ...
> }
>
> is that appropriate?
>
> Any help much appreciated, as is the work already put into
> this framework!
>
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>