Menu
▾
▴
[Jpolycache-users] FW: working version of an attribute driven cache
|
From: Aaron S. <aar...@ve...> - 2001-06-19 00:31:28
|
-----Original Message----- From: Aaron Smuts [mailto:aar...@ve...] Sent: Saturday, June 09, 2001 11:35 AM To: tur...@ja... Subject: RE: working version of an attribute driven cache I'm very happy to hear that you are interested. There is talk of a separate cache project in the commons. If it is acceptable when I get it a little more flexible, then it should go wherever it makes most sense. You tell me. I thought the jgl libraries were some form of lgpl. At least in 96 they were. If not I'll just rewrite whatever we are using. http://www.objectspace.com/products/voyager/libraries.asp I'm probably not using javaclass.jar. I need to clean up. It is not necessary. The sun jars should probably not be distributed with this application. It shouldn't be a problem to put a turbine service wrapper around it. I'll look into it. A few things, if you are going to be testing it. The lateral distribution is not optimized, to put it mildly. I only use it for invalidation for non remotely configured caches. If necessary some sort of multicasting or tcp socket server with success messages and retries could be added fairly easily. I'm talking about making it into a pluggable framework, but there are some issues. Mainly, you can't control the behavior of elements by element properties if you don't know what will be there. The plugins would have to be typed neatly. If multiple plugins were provided, the majority of the control would move to the region -- specifying what types of lateral distribution, remote stores, etc. to use. The element attributes would then be behavior type description: whether the element is eligible for any type of lateral distribution or disk spooling or remote storage and retrieval. . . . There are basically 4 types of caches, memory, disk, distributed (1 way ), and remote ( distributed 2 way ). Each of these could be a plugin and there could be as many of each as the programmer wanted. The last two could function similarly, the search access sequence could just exclude those that do no searching and the implementations could just return null for those methods. The necessary conjunction between memory and disk is difficult to break. Perhaps the disk cache could be treated as a runoff cache. There could be stores, replicators, and runoffs. Talk to you later. Aaron -----Original Message----- From: Jason van Zyl [mailto:jv...@ap...] Sent: Saturday, June 09, 2001 1:53 AM To: tur...@ja... Subject: Re: working version of an attribute driven cache On 6/8/01 4:00 PM, "Aaron Smuts" <AS...@th...> wrote: >> Aaron, >> Have you talked to the guys in the commons project about the stuff they are >> doing on caching? >> James > > > Not really. They were talking about a cache project in the commons and > there was interest in the turbine group, so I'll send this to both places. > Sorry about the spam, but the topic overlaps. > > I updated the zip and added some java-docs with uml. > http://www.psoft.net/~asmuts/ > > Since a few people emailed me directly, I'll give a rough overview of the > caching system. > That is quite the beast :-) Looks incredibly comprehensive! I see in the lib/ you have several jars. Are all of these used, and if so what are the licenses that apply to each of these JARs? I don't know the fine details of the Sun JARs and I have no idea what the license is with JGL. JavaClass, or what is now BCEL is fine, and so are the rest. This would be a fabulous addition, were you thinking of implementing this as a Turbine service? This would be fantastic timing because I have separated out the service framework from Turbine. It's almost fully decoupled which means if you add your service to Turbine it will soon be available to a much wider audience, I hope :-) I would definitely like to play with this next week sometime so I can give you some useful feedback. -- jvz. http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... --------------------------------------------------------------------- To unsubscribe, e-mail: tur...@ja... For additional commands, e-mail: tur...@ja... |
