RE: [simplestore] inital check in
A Cache should not be responsible for storing, should it? Then it isn't
a cache, but a DB...
I recommend to use some Storage interface for cache. You will be very glad
then you will decide at later time to store your applications state to
stable Storage, add transactions .
And even if you're going to do this, make a clean separation between the
cache and the persistency layer (do not assume it is a database. It can
be a filesystem, or a WebDAV system, or a Jisp system, ...)
I thing about cache as special kind of persistency layer.
I'm not even sure what you're going to do with this stored procedure...
It can be any kind interface for finders (EJB QL, JDO QL,SQL,OQL, My QL ,
Some API,).
procedures are more useful for updates .
procName.1={call some_proc(?)}
procName.2=SELECT something WHERE ID=?
procName.3=MyClass.someStaticMethod(1)
procName.4=protocol://www.something.com?id={0}
1=ProcDescriptorClass1
2=ProcDescriptorClass2
.
procName.descriptor=x
DB.call(procName, new Object{new Integer(0)});
May be it is not the best idea, but it works good for me.
Just giving my opinion, as I'm looking for a decent cache for some time
now and I'm considering using simplestore.
I can recomend a very special kind of cache OS Cashe:
http://www.opensymphony.com
If you use JSP in youe application.
tomK
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [simplestore] inital check in
Jep, and I do the same in my app, but a layer lower (_not_ in the cache,
but in the DB layer, which is the persistency layer I described above).
It may interesting for you if you do the same in your app.
I use cashe this way:
//implementation of StorageCacheHelper not the last implementation,
synchronized in the last Layer.
// Synchronization Layer implements the same interface.
Object call(String name, Object args [] ){
ResultWrapper wrp= null; // need wrapper for result if result is null
//Cashe implementation wraps java.util.Map interfce, real cashe
implementation
// depends on Map implementation, and can be reused in any kind of cache ,
it can be HashMap,WeakMap, //SomeMRUMap.
wrp = map.get(name, args );
if(wrp != null) return wrp.result;
Object result = myRealStorageLayerImplementsTheSameInterfaceAs_this
(name, args );
wrp = new ResultWrapper(result);
if(procDescriptor(name).flushCache()) {
procDescriptor(name).flush();
}
if(procDescriptor(name).useCashe()){
map.put( KeyPair(name,args), wrp );
}
return wrp.result;
}
}
it is not fragment from real implementation, my real implementation is more
complex and SQL dependant.
But I have plans to fix it.
Just giving my opinion, as I'm looking for a decent cache
for some time
now and I'm considering using simplestore.
I can recomend a very special kind of cache OS Cashe:
http://www.opensymphony.com
If you use JSP in youe application.
Thanks for the tip, I should look into this -- but that is the other
side (front-end) of the app, while I'm looking for a cache for the
back-end (persistency layer).
tomK
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [simplestore] inital check in
-Original Message-
From: Juozas Baliuka [mailto:[EMAIL PROTECTED]]
Sent: woensdag 16 januari 2002 13:49
To: Jakarta Commons Developers List
Subject: RE: [simplestore] inital check in
Jep, and I do the same in my app, but a layer lower (_not_
in the cache,
but in the DB layer, which is the persistency layer I
described above).
It may interesting for you if you do the same in your app.
I use cashe this way:
//implementation of StorageCacheHelper not the last implementation,
synchronized in the last Layer.
// Synchronization Layer implements the same interface.
Object call(String name, Object args [] ){
ResultWrapper wrp= null; // need wrapper for result if
result is null
//Cashe implementation wraps java.util.Map interfce, real cashe
implementation
// depends on Map implementation, and can be reused in any
kind of cache ,
it can be HashMap,WeakMap, //SomeMRUMap.
wrp = map.get(name, args );
if(wrp != null) return wrp.result;
Object result =
myRealStorageLayerImplementsTheSameInterfaceAs_this
(name, args );
wrp = new ResultWrapper(result);
if(procDescriptor(name).flushCache()) {
procDescriptor(name).flush();
}
if(procDescriptor(name).useCashe()){
map.put( KeyPair(name,args), wrp );
}
return wrp.result;
}
}
it is not fragment from real implementation, my real
implementation is more
complex and SQL dependant.
But I have plans to fix it.
Very interesting... believe it or not, but I just had started
refactoring of my cache and store in the way you describe here. Maybe I
finally start to understand you ;-)
tomK
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [simplestore] inital check in
queue, size9 153 removed from queue, size8 154 removed from queue, size7 161 removed from queue, size15 162 removed from queue, size14 163 removed from queue, size13 155 removed from queue, size12 156 removed from queue, size11 157 removed from queue, size10 158 removed from queue, size9 159 removed from queue, size8 160 removed from queue, size7 164 removed from queue, size15 165 removed from queue, size14 166 removed from queue, size13 167 removed from queue, size12 168 removed from queue, size11 169 removed from queue, size10 170 removed from queue, size9 171 removed from queue, size8 172 removed from queue, size7 173 removed from queue, size15 174 removed from queue, size14 175 removed from queue, size13 176 removed from queue, size12 177 removed from queue, size11 178 removed from queue, size10 179 removed from queue, size9 180 removed from queue, size8 181 removed from queue, size7 184 removed from queue, size15 185 removed from queue, size14 186 removed from queue, size13 187 removed from queue, size12 188 removed from queue, size11 189 removed from queue, size10 190 removed from queue, size9 182 removed from queue, size8 183 removed from queue, size7 191 removed from queue, size15 192 removed from queue, size14 193 removed from queue, size13 194 removed from queue, size12 195 removed from queue, size11 196 removed from queue, size10 197 removed from queue, size9 198 removed from queue, size8 199 removed from queue, size7 207 removed from queue, size15 208 removed from queue, size14 200 removed from queue, size13 201 removed from queue, size12 202 removed from queue, size11 203 removed from queue, size10 204 removed from queue, size9 205 removed from queue, size8 206 removed from queue, size7 209 removed from queue, size15 210 removed from queue, size14 211 removed from queue, size13 212 removed from queue, size12 213 removed from queue, size11 214 removed from queue, size10 215 removed from queue, size9 216 removed from queue, size8 217 removed from queue, size7 218 removed from queue, size15 219 removed from queue, size14 220 removed from queue, size13 221 removed from queue, size12 222 removed from queue, size11 223 removed from queue, size10 224 removed from queue, size9 225 removed from queue, size8 226 removed from queue, size7 230 removed from queue, size15 231 removed from queue, size14 232 removed from queue, size13 233 removed from queue, size12 234 removed from queue, size11 235 removed from queue, size10 227 removed from queue, size9 228 removed from queue, size8 229 removed from queue, size7 236 removed from queue, size15 237 removed from queue, size14 238 removed from queue, size13 239 removed from queue, size12 240 removed from queue, size11 241 removed from queue, size10 242 removed from queue, size9 243 removed from queue, size8 244 removed from queue, size7 iterating cache ... 252 251 250 249 248 247 246 245 254 253 0 At 07:40 PM 1/14/2002 +0100, you wrote: Juozas -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 8:20 PM To: Jakarta Commons Developers List Subject: RE: [simplestore] inital check in Hi, I read documentation tested all Reference types today. The problem exists, object is cleared before reference is queued. There is no way to flush expired object to stable storage if it has no strong references, but you can solve it this way : WRITE: 0. Test queue, clear pooled references. 1. write object . 2. Add internal strong and Weak reference, make it a new. 3. Put weak reference to cache. 4. release strong internal references from old objects. READ: 0. Test queue, clear pooled references. 1. Search in Cashe. 2. Load object, if not found. 3. Add internal strong and Weak references, make object a new. 4. Put weak reference to Cashe. 5. Release strong internal references from old objects. 6. return object. No need for background cleanup. I can implement this kind of cache, if it interesting for some body. I have some my cache implementations, but they are not very common :) Kool, mate. How about a MRU based Memory Store which is implemented with week reference. We can call it SoftMRUMemoryStore or something else. Just send compilable code and I will check it in for you. Keep sending patches, it's valuable ;-). Stand by for patches Gerhard At 05:28 PM 1/14/2002 +0100, you wrote: Juozas, From: Juozas Baliuka [mailto:[EMAIL PROTECTED]] StoreJanitorImpl: you can register your Memory Stores in this class. A background Thread checks if memory running slow in you JVM and if yes it frees some objects out of the registered Stores. Hi, I think it is better to use java.lang.ref.* to solve problems related to memory management. Application threads are not permitted in EJB container and I believe GC will do it better. It is from JDK documentation : Soft reference objects, which are cleared at the discretion of the garbage collector in response to memory
RE: [simplestore] inital check in
Hi Juozas, do you have interest to move your implemenation to my simplestore package? The only thing you have to do, is to replace your Store interface with my Store interface. I identify two objects we can need: - your MemoryStore, maybe it needs a new name. - your SynchronizedStore, that can we use for all our Stores. It would be kool to have it! What do you think? Greets Gerhard Juozas Baliuka [EMAIL PROTECTED] To: Jakarta Commons Developers List t[EMAIL PROTECTED] cc: 15.01.2002 Subject: RE: [simplestore] inital check in 13:46 Please respond to Jakarta Commons Developers List Hi, This is cache implementation, it will not work if key has strong referense on value (or have bugs). There is a very simple test in MemoryStore main method. I send a correct implementation for SoftReferenceMap in commons collections a month ago, but it was forgot. It is possible to implement cache with Map interface and memory store can wrap this map (it will be more useful). Is it interesting for anybody ? output from test : operations ... 1 removed from queue, size7 2 removed from queue, size15 3 removed from queue, size14 4 removed from queue, size13 5 removed from queue, size12 6 removed from queue, size11 7 removed from queue, size10 8 removed from queue, size9 9 removed from queue, size8 10 removed from queue, size7 11 removed from queue, size15 12 removed from queue, size14 13 removed from queue, size13 14 removed from queue, size12 15 removed from queue, size11 16 removed from queue, size10 17 removed from queue, size9 18 removed from queue, size8 19 removed from queue, size7 23 removed from queue, size15 24 removed from queue, size14 25 removed from queue, size13 26 removed from queue, size12 27 removed from queue, size11 28 removed from queue, size10 20 removed from queue, size9 21 removed from queue, size8 22 removed from queue, size7 29 removed from queue, size15 30 removed from queue, size14 31 removed from queue, size13 32 removed from queue, size12 33 removed from queue, size11 34 removed from queue, size10 35 removed from queue, size9 36 removed from queue, size8 37 removed from queue, size7 46 removed from queue, size15 38 removed from queue, size14 39 removed from queue, size13 40 removed from queue, size12 41 removed from queue, size11 42 removed from queue, size10 43 removed from queue, size9 44 removed from queue, size8 45 removed from queue, size7 47 removed from queue, size15 48 removed from queue, size14 49 removed from queue, size13 50 removed from queue, size12 51 removed from queue, size11 52 removed from queue, size10 53 removed from queue, size9 54 removed from queue, size8 55 removed from queue, size7 56 removed from queue, size15 57 removed from queue, size14 58 removed from queue, size13 59 removed from queue, size12 60 removed from queue, size11 61 removed from queue, size10 62 removed from queue, size9 63 removed from queue, size8 64 removed from queue, size7 69 removed from queue, size15 70 removed from queue, size14 71 removed from queue, size13 72 removed from queue, size12 73 removed from queue, size11 65 removed from queue, size10 66 removed from queue, size9 67 removed from queue, size8 68 removed from queue, size7 74 removed from queue, size15 75 removed from queue, size14 76 removed from queue, size13 77 removed from queue, size12 78 removed from queue, size11 79 removed from queue, size10 80 removed from queue, size9 81 removed from queue, size8 82 removed from queue, size7 83 removed from queue, size15 84 removed from queue, size14 85 removed from queue, size13 86 removed
RE: [simplestore] inital check in
-Original Message- From: Gerhard Froehlich [mailto:[EMAIL PROTECTED]] Sent: zaterdag 12 januari 2002 18:12 To: Jakarta Commons Developers List Subject: [simplestore] inital check in Hi all, I just booked in the first version of the simplestore into the sandbox area. [...] Just noticed that all your files are checked in as binary. This will not help CVS doing its task performantly... tomK -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [simplestore] inital check in
Hi, I think simple store is too simple :). I see some things to do for simple store. 1. Add meaningful exception classes 2. Add some helper key class for keys like Class + OID : Object key = new OID( myClass, someKey ); 3.Add simple finders and batch to store interface for optimizations: store(Map map); Iterator find( String myRegistredProcedure, String property); // SELECT it_is_from_procedure_descriptor FROM Some_Table WHERE myProc(property) = 1 Iterator find(Collection idCollection); 4. Ability to register and call stored procedures on sorage : registerProcedure(String alias,ProcedureDescriptor p); Object retValueOrValues = call(alias,paramArray); 5. Tranzaction listeners. At 01:09 PM 1/15/2002 +0100, you wrote: Hi Juozas, do you have interest to move your implemenation to my simplestore package? The only thing you have to do, is to replace your Store interface with my Store interface. I identify two objects we can need: - your MemoryStore, maybe it needs a new name. - your SynchronizedStore, that can we use for all our Stores. It would be kool to have it! What do you think? Greets Gerhard Juozas Baliuka [EMAIL PROTECTED] To: Jakarta Commons Developers List t [EMAIL PROTECTED] cc: 15.01.2002 Subject: RE: [simplestore] inital check in 13:46 Please respond to Jakarta Commons Developers List Hi, This is cache implementation, it will not work if key has strong referense on value (or have bugs). There is a very simple test in MemoryStore main method. I send a correct implementation for SoftReferenceMap in commons collections a month ago, but it was forgot. It is possible to implement cache with Map interface and memory store can wrap this map (it will be more useful). Is it interesting for anybody ? output from test : operations ... 1 removed from queue, size7 2 removed from queue, size15 3 removed from queue, size14 4 removed from queue, size13 5 removed from queue, size12 6 removed from queue, size11 7 removed from queue, size10 8 removed from queue, size9 9 removed from queue, size8 10 removed from queue, size7 11 removed from queue, size15 12 removed from queue, size14 13 removed from queue, size13 14 removed from queue, size12 15 removed from queue, size11 16 removed from queue, size10 17 removed from queue, size9 18 removed from queue, size8 19 removed from queue, size7 23 removed from queue, size15 24 removed from queue, size14 25 removed from queue, size13 26 removed from queue, size12 27 removed from queue, size11 28 removed from queue, size10 20 removed from queue, size9 21 removed from queue, size8 22 removed from queue, size7 29 removed from queue, size15 30 removed from queue, size14 31 removed from queue, size13 32 removed from queue, size12 33 removed from queue, size11 34 removed from queue, size10 35 removed from queue, size9 36 removed from queue, size8 37 removed from queue, size7 46 removed from queue, size15 38 removed from queue, size14 39 removed from queue, size13 40 removed from queue, size12 41 removed from queue, size11 42 removed from queue, size10 43 removed from queue, size9 44 removed from queue, size8 45 removed from queue, size7 47 removed from queue, size15 48 removed from queue, size14 49 removed from queue, size13 50 removed from queue, size12 51 removed from queue, size11 52 removed from queue, size10 53 removed from queue, size9 54 removed from queue, size8 55 removed from queue, size7 56 removed from queue, size15 57 removed from queue, size14 58 removed from queue, size13 59 removed from queue, size12 60 removed from queue, size11 61 removed from queue, size10 62 removed from queue, size9 63 removed from queue, size8 64 removed from queue, size7 69 removed from queue, size15 70 removed from queue, size14 71 removed from queue, size13 72 removed from queue, size12 73 removed from queue, size11 65 removed from queue, size10 66 removed from queue, size9 67 removed from queue, size8 68 removed from queue, size7 74 removed from queue, size15 75 removed from queue, size14 76 removed from queue, size13 77 removed from queue, size12 78 removed from queue, size11 79 removed from queue, size10 80 removed from queue, size9 81 removed from queue, size8 82 removed from queue, size7 83 removed from queue, size15 84 removed from queue, size14 85 removed from queue, size13 86 removed from queue, size12 87 removed from queue, size11 88 removed from queue, size10 89 removed from queue, size9 90 removed from queue, size8 91 removed from queue, size7 92 removed from queue, size15 93 removed from queue, size14 94 removed from queue, size13 95 removed from queue, size12 96 removed from queue, size11 97 removed from queue, size10 98 removed
RE: [simplestore] inital check in
-Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED]] Sent: dinsdag 15 januari 2002 18:37 To: Jakarta Commons Developers List Subject: RE: [simplestore] inital check in Hi, I think simple store is too simple :). I see some things to do for simple store. [...] 4. Ability to register and call stored procedures on sorage : registerProcedure(String alias,ProcedureDescriptor p); Object retValueOrValues = call(alias,paramArray); A Cache should not be responsible for storing, should it? Then it isn't a cache, but a DB... And even if you're going to do this, make a clean separation between the cache and the persistency layer (do not assume it is a database. It can be a filesystem, or a WebDAV system, or a Jisp system, ...) I'm not even sure what you're going to do with this stored procedure... Just giving my opinion, as I'm looking for a decent cache for some time now and I'm considering using simplestore. tomK -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [simplestore] inital check in
It is kind of cashe implementation for simple store At 01:09 PM 1/15/2002 +0100, you wrote: Hi Juozas, do you have interest to move your implemenation to my simplestore package? The only thing you have to do, is to replace your Store interface with my Store interface. I identify two objects we can need: - your MemoryStore, maybe it needs a new name. - your SynchronizedStore, that can we use for all our Stores. It would be kool to have it! What do you think? Greets Gerhard Juozas Baliuka [EMAIL PROTECTED] To: Jakarta Commons Developers List t [EMAIL PROTECTED] cc: 15.01.2002 Subject: RE: [simplestore] inital check in 13:46 Please respond to Jakarta Commons Developers List Hi, This is cache implementation, it will not work if key has strong referense on value (or have bugs). There is a very simple test in MemoryStore main method. I send a correct implementation for SoftReferenceMap in commons collections a month ago, but it was forgot. It is possible to implement cache with Map interface and memory store can wrap this map (it will be more useful). Is it interesting for anybody ? output from test : operations ... 1 removed from queue, size7 2 removed from queue, size15 3 removed from queue, size14 4 removed from queue, size13 5 removed from queue, size12 6 removed from queue, size11 7 removed from queue, size10 8 removed from queue, size9 9 removed from queue, size8 10 removed from queue, size7 11 removed from queue, size15 12 removed from queue, size14 13 removed from queue, size13 14 removed from queue, size12 15 removed from queue, size11 16 removed from queue, size10 17 removed from queue, size9 18 removed from queue, size8 19 removed from queue, size7 23 removed from queue, size15 24 removed from queue, size14 25 removed from queue, size13 26 removed from queue, size12 27 removed from queue, size11 28 removed from queue, size10 20 removed from queue, size9 21 removed from queue, size8 22 removed from queue, size7 29 removed from queue, size15 30 removed from queue, size14 31 removed from queue, size13 32 removed from queue, size12 33 removed from queue, size11 34 removed from queue, size10 35 removed from queue, size9 36 removed from queue, size8 37 removed from queue, size7 46 removed from queue, size15 38 removed from queue, size14 39 removed from queue, size13 40 removed from queue, size12 41 removed from queue, size11 42 removed from queue, size10 43 removed from queue, size9 44 removed from queue, size8 45 removed from queue, size7 47 removed from queue, size15 48 removed from queue, size14 49 removed from queue, size13 50 removed from queue, size12 51 removed from queue, size11 52 removed from queue, size10 53 removed from queue, size9 54 removed from queue, size8 55 removed from queue, size7 56 removed from queue, size15 57 removed from queue, size14 58 removed from queue, size13 59 removed from queue, size12 60 removed from queue, size11 61 removed from queue, size10 62 removed from queue, size9 63 removed from queue, size8 64 removed from queue, size7 69 removed from queue, size15 70 removed from queue, size14 71 removed from queue, size13 72 removed from queue, size12 73 removed from queue, size11 65 removed from queue, size10 66 removed from queue, size9 67 removed from queue, size8 68 removed from queue, size7 74 removed from queue, size15 75 removed from queue, size14 76 removed from queue, size13 77 removed from queue, size12 78 removed from queue, size11 79 removed from queue, size10 80 removed from queue, size9 81 removed from queue, size8 82 removed from queue, size7 83 removed from queue, size15 84 removed from queue, size14 85 removed from queue, size13 86 removed from queue, size12 87 removed from queue, size11 88 removed from queue, size10 89 removed from queue, size9 90 removed from queue, size8 91 removed from queue, size7 92 removed from queue, size15 93 removed from queue, size14 94 removed from queue, size13 95 removed from queue, size12 96 removed from queue, size11 97 removed from queue, size10 98 removed from queue, size9 99 removed from queue, size8 100 removed from queue, size7 101 removed from queue, size15 102 removed from queue, size14 103 removed from queue, size13 104 removed from queue, size12 105 removed from queue, size11 106 removed from queue, size10 107 removed from queue, size9 108 removed from queue, size8 109 removed from queue, size7 115 removed from queue, size15 116 removed from queue, size14 117 removed from queue, size13 118 removed from queue, size12 110 removed from queue, size11 111 removed from queue, size10 112 removed from queue, size9 113 removed from queue, size8 114 removed from queue, size7 119 removed from queue
RE: [simplestore] inital check in
-Original Message- From: Tom Klaasen (TeleRelay) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 15, 2002 6:06 PM To: Jakarta Commons Developers List Subject: RE: [simplestore] inital check in -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED]] Sent: dinsdag 15 januari 2002 18:37 To: Jakarta Commons Developers List Subject: RE: [simplestore] inital check in Hi, I think simple store is too simple :). I see some things to do for simple store. [...] 4. Ability to register and call stored procedures on sorage : registerProcedure(String alias,ProcedureDescriptor p); Object retValueOrValues = call(alias,paramArray); A Cache should not be responsible for storing, should it? Then it isn't a cache, but a DB... And even if you're going to do this, make a clean separation between the cache and the persistency layer (do not assume it is a database. It can be a filesystem, or a WebDAV system, or a Jisp system, ...) I'm not even sure what you're going to do with this stored procedure... Just giving my opinion, as I'm looking for a decent cache for some time now and I'm considering using simplestore. +10 with you here. Maybe we should rename it into simplecache. Gerhard God put me on this Earth to accomplish a certain number of things. Right now, I am so far behind I shall never die. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [simplestore] inital check in
-Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED]] Sent: Monday, January 14, 2002 3:34 AM To: Jakarta Commons Developers List Subject: Re: [simplestore] inital check in StoreJanitorImpl: you can register your Memory Stores in this class. A background Thread checks if memory running slow in you JVM and if yes it frees some objects out of the registered Stores. Hi, I think it is better to use java.lang.ref.* to solve problems related to memory management. Not if you want to do something with the elements, like keep the recenmtly used ones around and maybe flush the elements that aren't being used to disk. . . . The problem is that in most caches you can set the number of elements to be held in memory, but not the size, so you have to sort of guess how many you want to keep around. You could pass in an estimated size and let the cache keep track of the total, but that's not really any better. So, some sort of background cleanup might be nice. Application threads are not permitted in EJB container and I believe GC will do it better. It is from JDK documentation : Soft reference objects, which are cleared at the discretion of the garbage collector in response to memory demand. Soft references are most often used to implement memory-sensitive caches. Have fun Gerhard - Never share a foxhole with anyone braver than you are. - -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [simplestore] inital check in
Hi, persistence + Cache is one of the most common problems, in web applications. And I think recenmtly used algorythm is the best solution for this kind of cache. I saw a lot of cache implementations, but all of them implements Background Cleanup this way: Thread checks memory usage, object count in cache, size ... , locks cache for some time, removes internal references. It is not good. It costs resources and if you remove internal reference in cache it does not means you removed Object from memory, It is very possible you removed reference from old strong referenced object and hold internal references on old and unused ones. There is a better way. BTW GC collects old objects first on JVM I use, I don't know is it documented and standard way or is it good luck. Hi, I think it is better to use java.lang.ref.* to solve problems related to memory management. Not if you want to do something with the elements, like keep the recenmtly used ones around and maybe flush the elements that aren't being used to disk. . . . It is not a problem, you can have strong internal reference on recenmtly used objects. Reference returned from referenceQueue.pool() will not return null for weakReference.get(), if you use WeakReference registred with ReferenceQueue. You will not lose pooled objects, and can flush them to disk. The problem is that in most caches you can set the number of elements to be held in memory, but not the size, so you have to sort of guess how many you want to keep around. You could pass in an estimated size and let the cache keep track of the total, but that's not really any better. So, some sort of background cleanup might be nice. Agree, but I think it is better let GC to do its work. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [simplestore] inital check in -- cache (JCS plugins)
Aaron, From: Aaron Smuts [mailto:[EMAIL PROTECTED]] Hi: How do you find JISP? I added a disk auxiliary cache to JCS that uses it and it seems pretty fast and I haven't been able to get it to lock up. It uses a lot of disk space and doesn't take kindly to sharing files. I haven't tried to reliably re-use old files on startup yet. I haven't explored all of the features yet. I will introduce a Jisp based cache into Cocoon project as slow cache in the next release, I hope. I did some performance test against the current implementation and it seems to be very fast. I use in Cocoon the MRUMemoryStore as fast Cache and the Jisp based Store for Swaping. Like the Memory Management of a real OS (not Windows ;). The current implementation re-uses the old files on startup. Maybe we have to on/off this feature. How are you handling memory management? Take a look in the StoreJanitor. He's checks memory consumption with a simple formel with a periodic background thread. If memory running low he frees some objects out of the registered Memory Caches. Additonal the MRUMemoryStore has a Attribute called maxobjects. When maxobjects is reached the Store kicks out the least object! I'm looking for some alternative memory algorithms. I want to make memory management pluggable, but I need some alternatives to my LRU double-linked list first. Hi, kick in, take the MRUMemoryStore and the StoreJanitor. As I said I just ported the components from Cocoon and it's not 100%, yet. When you want change something, then feel free to do it. Send me a patch in the diff -u format and I will check it in. That would be kool!! A background Thread checks if memory running slow How do you determine slow? This is interesting. Ahem I mean low. A typo ;-). Gerhard skip/ A man with one watch knows what time it is, a man with two watches is never sure... (Albert Einstein) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [simplestore] inital check in
Juozas, From: Juozas Baliuka [mailto:[EMAIL PROTECTED]] StoreJanitorImpl: you can register your Memory Stores in this class. A background Thread checks if memory running slow in you JVM and if yes it frees some objects out of the registered Stores. Hi, I think it is better to use java.lang.ref.* to solve problems related to memory management. Application threads are not permitted in EJB container and I believe GC will do it better. It is from JDK documentation : Soft reference objects, which are cleared at the discretion of the garbage collector in response to memory demand. Soft references are most often used to implement memory-sensitive caches. Aha, it's a shame but I never looked into this. But I do it right now! Does anybody(you) have experiences with this soft references and how to use them? Yes I know RTFM ;-)! Gerhard A man with one watch knows what time it is, a man with two watches is never sure... (Albert Einstein) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [simplestore] inital check in -- cache (JCS plugins)
Sorry I mistook a typo slow for low. I looked over the code. Aaron -Original Message- From: Aaron Smuts [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 13, 2002 8:35 PM To: 'Jakarta Commons Developers List' Subject: RE: [simplestore] inital check in -- cache (JCS plugins) Hi: How do you find JISP? I added a disk auxiliary cache to JCS that uses it and it seems pretty fast and I haven't been able to get it to lock up. It uses a lot of disk space and doesn't take kindly to sharing files. I haven't tried to reliably re-use old files on startup yet. I haven't explored all of the features yet. How are you handling memory management? I'm looking for some alternative memory algorithms. I want to make memory management pluggable, but I need some alternatives to my LRU double-linked list first. A background Thread checks if memory running slow How do you determine slow? This is interesting. Cheers, Aaron -Original Message- From: Gerhard Froehlich [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 12, 2002 12:12 PM To: Jakarta Commons Developers List Subject: [simplestore] inital check in Hi all, I just booked in the first version of the simplestore into the sandbox area. I added following components: Store: the Store interface MRUMemoryStore: a MRU (Most Recently Used) Memory Store. JispFilesystemStore: a Jisp (http://www.coyotegulch.com/jisp/index.htmlbased) persistent Store. JispStringKey: A wrapper class for String Keys (unfortunately Jisp cames with a own Key class). TODO: add Integer and Long wrapper classes. StoreJanitor: the StoreJanitor interface. StoreJanitorImpl: you can register your Memory Stores in this class. A background Thread checks if memory running slow in you JVM and if yes it frees some objects out of the registered Stores. NOTE: I just merged the classes from the Cocoon project. I have first to test them fully. Maybe they are not 100% ready! Have fun Gerhard - Never share a foxhole with anyone braver than you are. - -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:commons-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [simplestore] inital check in
StoreJanitorImpl: you can register your Memory Stores in this class. A background Thread checks if memory running slow in you JVM and if yes it frees some objects out of the registered Stores. Hi, I think it is better to use java.lang.ref.* to solve problems related to memory management. Application threads are not permitted in EJB container and I believe GC will do it better. It is from JDK documentation : Soft reference objects, which are cleared at the discretion of the garbage collector in response to memory demand. Soft references are most often used to implement memory-sensitive caches. Have fun Gerhard - Never share a foxhole with anyone braver than you are. - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
