Transfer cache synchronization across a cluster / Railo

10 views
Skip to first unread message

whostheJBoss

unread,
Sep 19, 2009, 10:06:35 PM9/19/09
to transfer-dev
I've been exploring options for synchronizing the Transfer cache
across multiple servers in a cluster and am looking for some advice. I
had posted this to the Railo list and have been working with Gert, but
I still don't have a solution yet and thought maybe some cleverness
would come from this list.

I came across Sean's post:
http://corfield.org/blog/index.cfm/do/blog.entry/entry/Transfer_Cache_Synchronization_in_a_Cluster

This uses messaging and gateways, neither of which are currently
supported in Railo (to my knowledge, unless there are some esoteric
settings or
code buried somewhere I haven't examined). I was thinking perhaps
there might be a solution using the cluster scope. Much like how we
do:

<scope type="instance">

I need to do:

<scope type="cluster">

This would mean that for the scopes attribute of the objectCache that
I would need to be able to add "cluster".

Is the scoping of the cache complex or should it be fairly
straightforward to add?

Any other suggestions are very welcome! Thanks!

p.s. Mark, if you see this, I've tested double on everything but
Oracle at this point and so far it's smooth sailing!

Mark Mandel

unread,
Sep 20, 2009, 10:15:54 PM9/20/09
to transf...@googlegroups.com
It really depends on how the cluster cache does serialisation across the wire.

TO's have a reference to Transfer in them, so you can get into some pretty nasty synchronisation issues, if a TO gets sync'd then that Grabs Transfer, which then attempts to grab the cache.... eeek!

I've been rolling around in my head how to do a pluggable Cache architecture with Transfer, and pretty much do away with the tight integration that Transfer has with its current Caching mechanism.

Its started as an idea, because I wanted to replace the Transfer cache with eHCache (which would solve a lot of memory issues) now that I have some great new integration tools with JavaLoader 1.0.  But that would mean that it wouldn't be compatable with CF7, as it's on Java 1.4. Talking about this on twitter, the idea of having a pluggable architecture came up, and I'm thinking its a very good idea.

This would mean you could write your own cache implementation with any sort of caching engine, be it distributed or otherwise, you could do it with layers, you could do all sorts of very cool things.

At this stage, its just an idea rolling around inside my head, but its the sort of direction I'm thinking of heading.... what do you guys think?

Mark
--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

whostheJBoss

unread,
Sep 21, 2009, 2:10:53 AM9/21/09
to transfer-dev
Ahh, yes, we don't need the entire cache being taxi'd around!

The pluggable stuff sounds like where it's at, I will need to examine
the details more before I can form a real opinion or provide any
input.

I would be happy just being able to do what Sean was describing, which
is just to tell the other Transfer caches in the cluster to discard
their copy whenever the same object is updated on any of the other
instances.

So, if I had an object, say "users.user" with primary key 25, I want
to update the other two Transfer caches to discard it using
discardByClassAndKey() whenever I make changes. (I will want to be
able to choose if I want to do it after update, delete, save, etc)

Right now I just need to figure out how to get the caches talking.

Thoughts?

On Sep 20, 7:15 pm, Mark Mandel <mark.man...@gmail.com> wrote:
> It really depends on how the cluster cache does serialisation across the
> wire.
>
> TO's have a reference to Transfer in them, so you can get into some pretty
> nasty synchronisation issues, if a TO gets sync'd then that Grabs Transfer,
> which then attempts to grab the cache.... eeek!
>
> I've been rolling around in my head how to do a pluggable Cache architecture
> with Transfer, and pretty much do away with the tight integration that
> Transfer has with its current Caching mechanism.
>
> Its started as an idea, because I wanted to replace the Transfer cache with
> eHCache (which would solve a lot of memory issues) now that I have some
> great new integration tools with JavaLoader 1.0.  But that would mean that
> it wouldn't be compatable with CF7, as it's on Java 1.4. Talking about this
> on twitter, the idea of having a pluggable architecture came up, and I'm
> thinking its a very good idea.
>
> This would mean you could write your own cache implementation with any sort
> of caching engine, be it distributed or otherwise, you could do it with
> layers, you could do all sorts of very cool things.
>
> At this stage, its just an idea rolling around inside my head, but its the
> sort of direction I'm thinking of heading.... what do you guys think?
>
> Mark
>
> On Sun, Sep 20, 2009 at 12:06 PM, whostheJBoss
> <dotfus...@changethings.org>wrote:
>
>
>
>
>
>
>
> > I've been exploring options for synchronizing the Transfer cache
> > across multiple servers in a cluster and am looking for some advice. I
> > had posted this to the Railo list and have been working with Gert, but
> > I still don't have a solution yet and thought maybe some cleverness
> > would come from this list.
>
> > I came across Sean's post:
>
> >http://corfield.org/blog/index.cfm/do/blog.entry/entry/Transfer_Cache...
>
> > This uses messaging and gateways, neither of which are currently
> > supported in Railo (to my knowledge, unless there are some esoteric
> > settings or
> > code buried somewhere I haven't examined). I was thinking perhaps
> > there might be a solution using the cluster scope. Much like how we
> > do:
>
> > <scope type="instance">
>
> > I need to do:
>
> > <scope type="cluster">
>
> > This would mean that for the scopes attribute of the objectCache that
> > I would need to be able to add "cluster".
>
> > Is the scoping of the cache complex or should it be fairly
> > straightforward to add?
>
> > Any other suggestions are very welcome! Thanks!
>
> > p.s. Mark, if you see this, I've tested double on everything but
> > Oracle at this point and so far it's smooth sailing!
>
> --
> E: mark.man...@gmail.com
Reply all
Reply to author
Forward
0 new messages