You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "F.R. Da Costa Gomez" <dc...@fixed.com> on 2003/03/18 12:48:33 UTC
Best place to initialize central services
Hi all,
Is the folowing assumption correct?
The engine is the best place to initialize things like database, service
and other pooled 'managers'. These are basically services supplied to
users of the system that have nothing to do with the UI.
Basically I want to use a multi-threaded dbMgr (connection pool) to do
my db-stuff with. Q is however what is the best place to init this Mgr.
Thx,
Fermin DCG
Re: Best place to initialize central services
Posted by "F.R. Da Costa Gomez" <dc...@fixed.com>.
Ok, let me try to summarize to see whether I am grasping what is being
suggested.
1. Assuming a user is authenticated he *could* be represented by *1* and
only 1 Visit object which is available for all the pages this particular
user can utilize.
2. Pages are taken from a pool of pages. After a user has finished with
it, it is released into the pool (the page, not the user). Does this
imply that the corresponding java class is also behaving ijn a similar
fashion to the page component (i.e. available via a pool and released
when finished)?
3. The Global mechanism allows me to define 1 or more global 'things'
accessible from every page. Is this a save assumtion?
4. Assuming 2 & 3 are correct interpretations then it could be very
beneficial to use the concept of a WU (a term I first saw introduced by
someone on the list, sorry I can't find the name in my mailbox anymore).
Since the task at hand is fully defined (incl screens etc.) one would
fire the job(s) at a particular global 'thing', get one's reply and go
on with business. Obviously this would only work if and when the WU is
not shared but instantiated more then once. This obviously depends on
the goings on in point two.
Slightly different Q:
If one uses a fully transparent OODB would it then also be possible to
use that for the Visit object (without using serializable). Just asking
because I'm working with an OODB which would allow have a larger
persistent set of data attached without having to worry about sizing
issues (maps with authorized WUs etc.)
Thx in adv
Fermin DCG
Howard M. Lewis Ship wrote:
>You may also want to check into application extensions. These started with
>an idea by Geoff. Basically, they are like page helper beans, but are in
>the application specification. They can load on startup if you like. As
>usual, the idea is to avoid Mechanical Coding Injury.
>
>In addition, 2.3 added the new Global mechanism (like the Visit, but shared
>by all sessions) which is a good place for things like database pools and
>EJB homes.
>
>
RE: Best place to initialize central services
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
You may also want to check into application extensions. These started with
an idea by Geoff. Basically, they are like page helper beans, but are in
the application specification. They can load on startup if you like. As
usual, the idea is to avoid Mechanical Coding Injury.
In addition, 2.3 added the new Global mechanism (like the Visit, but shared
by all sessions) which is a good place for things like database pools and
EJB homes.
--
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: Tuesday, March 18, 2003 7:27 AM
> To: Tapestry users; joe@panmachine.biz
> Cc: dcg@fixed.com
> Subject: Re: Best place to initialize central services
>
> I think, reading this, that it appears that the difference
> between Joe's approach and that which I gleaned from the Vlib
> example, is that the Vlib example does just this sort of
> "lazy" initialization. Of course, I may not fully understand
> what's going on in the Vlib example, as it is tied to EJB
> stuff that I don't yet fully grok ...
>
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
Re: Best place to initialize central services
Posted by Bill Lear <ra...@zopyra.com>.
On Tuesday, March 18, 2003 at 08:13:47 (-0500) joe panico writes:
>...
>Also, if you want services that run indepedent of any UI, i.e. can
>start threads without any UI requests, ApplicationServlet.init is a
>good spot. You can have the WebApplication load the
>ApplicationServlet on start-up, rather than on the first user
>request, so that init() will be called when you launch the "servlet
>container". However, if you tried to launch centralized services from
>Engine, they would not start until a user request was received.
I think, reading this, that it appears that the difference between
Joe's approach and that which I gleaned from the Vlib example, is that
the Vlib example does just this sort of "lazy" initialization. Of
course, I may not fully understand what's going on in the Vlib
example, as it is tied to EJB stuff that I don't yet fully grok ...
Bill
Re: Best place to initialize central services
Posted by joe panico <jo...@panmachine.biz>.
The Engine is probably _not_ the best place to initialize program aspects that
are independent of the UI, because Engine's are intimately tied to the UI. The
services you describe (connection pooling), span all users, that is they are
at a more basic level than a user. But the Engine is a per-HTTPSession construct.
In Pixory, "services" (which are not necessarily tied to any particular UI
constructs) are started in the ApplicationServlet.init(). The
ApplicationServlet is the most centralized spot in a Tapestry application, so
it's a good place for centralized (application-wide) services.
Also, if you want services that run indepedent of any UI, i.e. can start
threads without any UI requests, ApplicationServlet.init is a good spot. You
can have the WebApplication load the ApplicationServlet on start-up, rather
than on the first user request, so that init() will be called when you launch
the "servlet container". However, if you tried to launch centralized services
from Engine, they would not start until a user request was received.
regards,
joe
--
Open WebMail Project (http://openwebmail.org)
---------- Original Message -----------
From: "F.R. Da Costa Gomez" <dc...@fixed.com>
To: Tapestry users <ta...@jakarta.apache.org>
Sent: Tue, 18 Mar 2003 12:48:33 +0100
Subject: Best place to initialize central services
> Hi all,
>
> Is the folowing assumption correct?
> The engine is the best place to initialize things like database,
> service and other pooled 'managers'. These are basically services
> supplied to users of the system that have nothing to do with the UI.
> Basically I want to use a multi-threaded dbMgr (connection pool) to
> do my db-stuff with. Q is however what is the best place to init
> this Mgr.
>
> Thx,
>
> Fermin DCG
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
------- End of Original Message -------
Re: Best place to initialize central services
Posted by Bill Lear <ra...@zopyra.com>.
On Tuesday, March 18, 2003 at 12:48:33 (+0100) F.R. Da Costa Gomez writes:
>Hi all,
>
>Is the folowing assumption correct?
>The engine is the best place to initialize things like database, service
>and other pooled 'managers'. These are basically services supplied to
>users of the system that have nothing to do with the UI.
>Basically I want to use a multi-threaded dbMgr (connection pool) to do
>my db-stuff with. Q is however what is the best place to init this Mgr.
Not sure if I can authoritatively answer this, but from reading the
documentation about the engine, it appears so ("it is a central object
[that] provides services to the pages and components utilized during
the request cycle": Chapter 5, Developers Guide; "The engine exists to
provide core services to the pages and components that make up the
application.": API documentation for interface IEngine). I'd say
DB services qualify.
If you have a look at the Vlib example, it delegates this work to
other classes (see IBookQuery.java, BookQueryBean.java, and
OperationsBean.java for example), but the engine is still the central
place from which the other components in Vlib ultimately get DB
connections (hidden deeply away, of course) through these (and other)
class instances.
Bill
RE: Best place to initialize central services
Posted by "Howard M. Lewis Ship" <hl...@attbi.com>.
Application extensions are another good idea. they are much like helper
beans, in that you give them a name and a class and can set their
parameters.
App extensions may be hooks used by Tapestry, but are also there for
app-specific usage.
<extension> tag, within <application>
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry
> -----Original Message-----
> From: F.R. Da Costa Gomez [mailto:dcg@fixed.com]
> Sent: Tuesday, March 18, 2003 6:49 AM
> To: Tapestry users
> Subject: Best place to initialize central services
>
>
> Hi all,
>
> Is the folowing assumption correct?
> The engine is the best place to initialize things like
> database, service
> and other pooled 'managers'. These are basically services supplied to
> users of the system that have nothing to do with the UI.
> Basically I want to use a multi-threaded dbMgr (connection
> pool) to do
> my db-stuff with. Q is however what is the best place to init
> this Mgr.
>
> Thx,
>
> Fermin DCG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>