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 <[email protected]> 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 > <[email protected]>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: [email protected] > T:http://www.twitter.com/neurotic > W:www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
