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

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

I'd like to get some ideas on how caching might be integrated into
Turbine and Torque.

At my job I've implemented a pattern where data access goes through
managers that return value objects, except on large result sets (they
are cached where efficient and sorted using a comparator sorter on
scaled down value objects or on ArrayLists of arrays).

The managers return simple lists for drop downs and the value objects
for detail pages.  The caching is done at the manager level.  Data comes
into our application via remote check processing centers and is parsed
by standalone parsers.  Credit card and ACH transactions processed in
batch more also run in standalone mode.  All the processes access the
data via the same managers and all communicate invalidations through the
cache.  Conglomerate data is invalidated by adding the summary data
cache name to the list of caches to notify of the changes for items.
The local and mid-tier caching system keeps the 12 or so machines in
synch.  It works nicely.  Of course some data access is not cached since
it needs to be 100% accurate. . . .

(Off the subject but a Visa Gateway server certified by Vital would be a
fantastic jakarta project.  If you ever needed to handle credit card
processing, you could turn to an open source solution!  I'm sure I could
use it in future jobs.  Right now you have to buy something less
complicated than JCS that costs at least 20k to send files to the credit
card processing network.  I'm all for starting the project if anyone is
interested.  You can build a standalone server that takes basic input,
formats a file and sends it to a configured provider.  There are some
tricky error handling issues, but it would be an extremely useful
project, but it may put some people out of business.)

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


 


--
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>

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>