I believe that plugin in a "in memory" store could be a good option. That would enable us to really make the benching difference between what is the JDBC stuff (and hence the serialization going on) and what is really the container work. I suspect I know the answer to that one, as the container will take about <<0.1ms to go through the stacks and the JDBC stuff will take >>0.1 ms. What I am interested in are the relative times. 2 reasons for that: 1- Where do we really need to optimize our stuff? my mind set right now is that the serialization is really where we lose time in computing in general (ex: XML-RPC). I already sent an email calling for fastJAWS optimizations. 2- By putting the inMemory plugin we allow people to get a REAL feel and BENCH of the THROUGHPUT of JBoss. I am starting to believe that we are above the rest in terms of the scalability due to the logical stubs. A company where I just went said that seeing JBoss take 12,000 invocations on a "LAPTOP" and crunching through it eventually was an inspiring thing to see and really made the difference with WebLogic. The speed is not the issue it is the linear scalability of these puppies that we really want to stretch. When we benched on 10way solaris, we really saw that 5000 clients could scale linearly... on Windows (and a small box) we went to 1000 clients without ANY DEGRADATION in the throughput. That is LINEAR SCALABILITY on the server side and that is really an amazing number if we can confirm it. It will give us so much FIRE POWER in terms of marketing. The bottom line on this is simple. If we put the simple "in mem" persistence then the users can trouble shoot that it is the CMP stuff that is taking time because the queries are silly. Finally in that plugin I believe we will put a map of all the instances created, it will be simple to implement the "findByPrimaryKey" by just looking up the key in the map. It will be simple to implement the "findAll" by just returning the whole index that is in there (getKeys or something). It will be more complex and bulky in memory to implement the findByName pattern since we would need to create a map of the hashed fields. Still feasable just more CPU intensive. The initialization of the plugin should also READ AND WRITE THE WHOLE MAP to the database (we might have some problems with the non serializable instances but that is not what the class is meant for). A final policy we can implement here is have the state saved to file or DB (native) every other seconds with an "asynchrounous call" (say a JMS queue). THIS WILL BE VERY USEFUL for "soft-ball" requirements of state saving even in real life. Finally I believe we should offer this little class to be extended so that people can put their own finders AT THE OBJECT LEVEL. In short I view this class under the double advantage of giving us a clear probe in the time domain (EC-Perf is a joke imho) of JBoss by getting rid of the serialization. I am also pretty sure that some folks will be using this "soft-ball-ok" hack in their own code. If you are interested please let the board know. marc _________________ Marc Fleury, Ph.D [EMAIL PROTECTED] _________________ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
