Re: torque caching and JCS as a turbine service (credit card processing)

[Jon Scott Stevens <jo...@latchkey.com>]

on 2/3/02 7:51 PM, "Aaron Smuts" <aa...@verizon.net> wrote:

> Back to the point.  I could have the managers use Torque for data access
> and the managers could still handle the caching, but it might be nice to
> have torque handle some of this on its own.  The complexity of handling
> group dependencies on items matching certain parameters might be a mess,
> but for item level stuff it would be nice.  Sort of like Javlin (sp?)
> and an appserver all in one.
> 
> Where might caching fit into torque?
> 
> What about JCS as a turbine service?
> 
> Aaron

Just some thoughts...

I need caching in Torque as well...I suspect that all of the doSelect(),
doUpdate(), doDelete() methods in the Peers would need to be made
intelligent about caching. We would also want the field level methods (the
get/setters) and the save() method in the BO to help with invaliding and
updating the cache. You also would need to add some sort of dependency
tracking into the objects which are related to each other through joins in
the database so that when one changes, the other changes as well. This part
can turn into a logistical nightmare if you have several levels of joins.

Of course all of this would need to be able to be turned off at a moments
notice as well...however, if it is done right, it should be unnoticeable
when caching is turned on because the invalidation/updating will be so
efficient and work so well, that you won't even know that an object came
from the database or from the cache...

-jon


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: torque caching and JCS as a turbine service (credit cardprocessing)

[Jon Scott Stevens <jo...@latchkey.com>]

on 2/4/02 5:39 PM, "Aaron Smuts" <aa...@verizon.net> wrote:

> I wonder if caching should be above or on top of Torque rather than
> within.

I'm not really sure that putting it on top of Torque will achieve the
desired effect of transparent caching. Something like that would need to
come from within.

That said, it should be easily disabled if needed. So, the caching methods
should always call: "isCacheEnabled()" or something like that at the top of
their execution.

-jon


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: torque caching and JCS as a turbine service (credit cardprocessing)

[Aaron Smuts <aa...@verizon.net>]

> -----Original Message-----
> From: Jon Scott Stevens [mailto:jon@latchkey.com]
> Sent: Monday, February 04, 2002 12:46 PM
> To: turbine-dev
> Subject: Re: torque caching and JCS as a turbine service (credit
> cardprocessing)
> 
> on 2/3/02 7:51 PM, "Aaron Smuts" <aa...@verizon.net> wrote:
> 
> > Back to the point.  I could have the managers use Torque for data
access
> > and the managers could still handle the caching, but it might be
nice to
> > have torque handle some of this on its own.  The complexity of
handling
> > group dependencies on items matching certain parameters might be a
mess,
> > but for item level stuff it would be nice.  Sort of like Javlin
(sp?)
> > and an appserver all in one.
> >
> > Where might caching fit into torque?
> >
> > What about JCS as a turbine service?
> >
> > Aaron
> 
> Just some thoughts...
> 
> I need caching in Torque as well...I suspect that all of the
doSelect(),
> doUpdate(), doDelete() methods in the Peers would need to be made
> intelligent about caching. We would also want the field level methods
(the
> get/setters) and the save() method in the BO to help with invaliding
and
> updating the cache. You also would need to add some sort of dependency
> tracking into the objects which are related to each other through
joins in
> the database so that when one changes, the other changes as well. This
> part
> can turn into a logistical nightmare if you have several levels of
joins.
> 

I wonder if caching should be above or on top of Torque rather than
within.

> Of course all of this would need to be able to be turned off at a
moments
> notice as well...however, if it is done right, it should be
unnoticeable
> when caching is turned on because the invalidation/updating will be so
> efficient and work so well, that you won't even know that an object
came
> from the database or from the cache...
> 
> -jon
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:turbine-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-dev-
> help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>