commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juozas Baliuka <bali...@mwm.lt>
Subject Re: [simplestore] changing the interface
Date Sun, 20 Jan 2002 10:52:45 GMT

>
>In our interface there is only too method remaining:
>Store getNextStore() and
>void free()
>
>free(), because that's the method which throws out the not needed object 
>depending
>on the alghorithm!

Yes "free()" can be useful for some  stores, in some cases service can 
recover itself,
in some cases throw something like "NotAvailableException" ,
it is kind of tree  from single directories ( List ) :

Service1
      ========> Servise2
                         =======> Service3
                                            ==========>
                                                  .............................

There are a lot ways to handle "NotAvailableException", in some cases it is 
possible to log failure (send SMS,email ...) and
remove some service from list.


Service1
      ========>[ Servise2    ]
                        [ === Dead ==]
                        Service3
                        ==========>
                                                  .............................



It can be some database, remote service .... (ARMI can be used, but its 
portabilty and transparensy is not clear for me at this time)

BTW don't think I think ARMI  is bad, I must know everything "bad", before 
I use it, "good" I can read myself. It is kind of missunderstanding, I have 
some communication problems, english is not my native language, I lean it 
myself and I don't know
diplomatic words. The same is about Cocoon,DCOM,CORBA, JAVA .... . It is 
about code and frameworks, not about persons,  organizations, companies 
..... .

  Next we can do easy to remove SoftMemoryStore it has nothing "good" it 
dublicates ideas from
  org.apache.commons.collections.SoftRefHashMap, but this class must be 
fixed, it will not work
  or we must use "free()" it will iterate all entries in map it is no need 
to do it for memory stores. "Bad" :). The same is about MRUMemoryStore 
(MRUMap).
We don't need a lot of implementations for memory store, we can have a 
single  class MemoryStore it
depends only on map implementation, look at 
org.apache.commons.collections.LRUMap (I must work good).
it can be implemented like this :
class MyMemoryStore extends MemoryStore{
   public MyMemoryStore(int param){
       super(new org.apache.commons.collections.SoftRefHashMap(param));// 
purge method must be fixed.
  }
  // no need to implement Store methods they are implemented in MemoryStore
// any map implementation can be used, there are some in java.util.*, some 
in org.apache.commons.collections.*
}
Simple solution. isn't it ? Work on maps for memory Store, it will be more 
useful for all in commons.

I believe you like code reuse and don't afraid to remove "bad" code. I am 
newer afraid to do it, it is very usual
for "good" projects.

It is very possible I will not write emails for you














>   Gerhard
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message