I once read somewhere that JBoss implements CMP by translating EJB-QL (or the older JAWS style expressions) into SQL.
This means that whenever a finder is invoked, Jboss must query the database. If you are in the situation where you can use commit option A, this is a bit of a bottleneck. The truth is database access is always going to be slow. JDBC typically runs over TCP/IP (even when the database is local) so there is an IO hit, and of course there is the performance hit of marshalling/unmarshalling the data in and out of JDBC. With EJB however, it is only really necessary to go to the database when you are writing data. In many (most?) applications there are typically far more read operations than write operations. Therefore caching information in memory can give massive performance benefits. If JBoss didn't need to go to the database during finder methods, CMP bean performance could benefit greatly. My question is therefore, does it sound plausible to write an in-JVM implementation of EJB-QL, which doesn't rely on the database to perform queries? To me, it seems as though this would be possible. You would cache all the beans of given types in memory. It should be possible to organise them using virtual indexes which are derived from the finder methods. When a finder method is invoked, a pure Java implementation of EJB-QL plucks out the appropriate beans from memory, without a single IO hit (excluding clustering issues). To me, this approach would have another great architectural benefit to JBoss: it would make it relatively easy to use non-JDBC data stores. Any thoughts? -- Peter Beck BEng (hons) - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-+-+-- Experts in e-business and e-commerce ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
