I'll cheerfully accept correction or amplification of anything I say here
on this subject. I have no practical experience with PACs whatsoever, and
my EJB experience is limited to doing the labs in the ND5 upgrade course.
An advantage of running your cache manager under either a PAC or ND's EJB
implementation is that it would exist in a separate service and the CP (one
or many) would communicate with it through a CORBA interface. Thus you
could have a loose coupling between CP objects and cache manager objects,
instead of the 1-1 relationship that would be implied if your cache manager
objects were instantiated inside the CP.
If you built a PAC, you would have total control of everything that happens
between the CORBA interface and your cache object. You ought to be able to
read in one copy of the data, and direct all requests through the interface
to that one copy. You would have to learn how to use the PAC SDK and
design all of the management stuff to do that.
If you make your cache manager become an EJB, whether by changing it or by
creating an EJB to contain it, then you will be able to use the EJB service
instead of rolling your own via the PAC SDK. But then you would have to
accept the design and limitations of the EJB service. I'm flying a little
blind here, because my ND5 stuff is in a box that hasn't been unpacked (in
the process of moving office). Brendan's point about session beans vs.
entity beans is well taken, and ND does not yet (but says it will) support
entity beans. In general, ND's approach seems to be to maintain multiple
copies of the various objects, EJBs included.
-- Curt Springer, Team ND
At 10:25 AM 4/16/99 -0700, Johnston, Brendan wrote:
>I have implemented a number of small caches which have not been generalized.
>They Cache small numbers of codes etc, which are assumed to be constant
>during the execution of the program.
>
>I chose to implement them in data objects (usually the one which fills the
>cache).
>This means that the cache is duplicated for each thread.
>This removes any need to waste brain time thinking about synchronization and
>makes the cache very fast.
>However the cost is extra time filling the cache and extra memory.
>
>If you want to share objects across sessions you should not use session
>beans, Entity beans are for this.
>
>Since ND runs in multiple processes on different physical machines a global
>cache seems problematic.
>
>Here are some ideas:
>
>1. GlobalSessionObjects might help you
>2. If there is a lot of data and you want to access it from multiple ND
>processes, put the cache in a database
>
>Brendan Johnston
>TeamND
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, April 16, 1999 6:53 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [ND] Implementing a Cache Manager
>
> Curt,
>
> Thanks for your input.
>
> My requirement is to share the data managed by the Cache Manager
>component across multiple sessions.
> If possible, I would like to implement with EJB (Statefull?) but
>not quite sure if EJB would be a right model to implement
> a shared data service. For one, I have to ensure that there is only
>one instance of this bean. Otherwise, cached data will
> splitter across multiple instances of EJB (which may be running in
>different JVM)...and then I have to deal with locating right
> instance of bean etc.
>
> You mentioned about data caching in ND5. Where and how is this
>being done? In JDBC service?
>
> Is PAC more appropriate model than EJB in ND5 for some thing like
>this?
>
> Raj
>
>
>
> Curt Springer <[EMAIL PROTECTED]> wrote:
> >First off, you should look at the data caching feature in ND5 to
>see if>that might do something for you.
> >
> >Anyhow, I've got some stuff that caches rows, on a session basis.
> >Question: are you trying to cache data for use in one session or
>across
> >multiple sessions?
> >
> >If for one session, I would put the data into a session object. In
>each
> >page get the session object in onBeforeLoad or button/href web
>events, put
> >it back at the end of processing. I keep rows from up to 30 tables
>in
> >memory on this basis.
> >
> >At one point, I had a singleton class, and it killed performance.
>I found
> >that it worked to have one object of the class owned by each page
>class,
> >since much of ND's object instantiation model is driven at the page
>level.
> >
> >You should also look at EJB in ND5. That would be a cleaner
>implementation
> >than anything available in ND4, except maybe a PAC.
> >
> >-- Curt Springer, Team ND
> >
> >At 04:08 PM 4/15/99 -0800, [EMAIL PROTECTED] wrote:
> >>In our architecture, we have a Cache Manager component which
>caches the
> >data (in memory) to
> >>reduce trips to the DB. Cache Manager is a singleton, i.e. there
>is only
> >one instance of Cache Manager.
> >>What is the best way to implement the Cache Manager in ND so that
>the
> >cached data
> >>is accessible to other services?
> >>
> >>Thanks...
> >>
> >>Raj
> >>
>
>>>_________________________________________________________________________
> >>
> >>For help in using, subscribing, and unsubscribing to the
>discussion
> >>forums, please go to:
>http://www.netdynamics.com/support/visitdevfor.html
> >>
> >>For dire need help, email: [EMAIL PROTECTED]
> >>
>
>
>_________________________________________________________________________
>
> For help in using, subscribing, and unsubscribing to the discussion
> forums, please go to:
>http://www.netdynamics.com/support/visitdevfor.html
>
> For dire need help, email: [EMAIL PROTECTED]
>_________________________________________________________________________
>
>For help in using, subscribing, and unsubscribing to the discussion
>forums, please go to: http://www.netdynamics.com/support/visitdevfor.html
>
>For dire need help, email: [EMAIL PROTECTED]
>
_________________________________________________________________________
For help in using, subscribing, and unsubscribing to the discussion
forums, please go to: http://www.netdynamics.com/support/visitdevfor.html
For dire need help, email: [EMAIL PROTECTED]
