This one time, at band camp, tek1 said:
t>At 17:16 03/05/30 +0000, you wrote:
t>>This one time, at band camp, tek1 said:
t>>
t>>t>Just read an interesting article about performance improvement using JBoss,
t>>t>which I am using with Castor.
t>>t>
t>>t>The article was focused on EJB, but the author talked about a "Cache
t>>t>Invalidation Bus" to notify the cache of other JBoss instances that a
t>>t>particular entity was modified (in another JBoss instance) and that the
t>>t>entity should be removed from the cache of the other JBoss instances.
t>>t>
t>>t>http://www.onjava.com/pub/a/onjava/2003/05/28/jboss_optimization.html?page=2
t>>t>
t>>t>
t>>t>Perhaps a similar concept could be adopted for clustering in Castor?
t>>t>
t>>t>Is anyone currently using Castor in a clustered environment?
t>>
t>>JBoss accomplishes via JavaGroups, a project by Bela Ban. Actually
t>>I've been pondering this with my cache refactoring ideas and I've
t>>been meaning to speak with Bela about it.
t>>
t>>My idea is to provide some default caching mechanism but make this
t>>layer pluggable so that any caching mechanism could easily be plugged
t>>in, including a distributed cache. This requires the use of a well
t>>known API (e.g. possibly JSR 107 via http://jcache.sourceforge.net/,
t>>http://sourceforge.net/projects/ojc or something similar) so that this
t>>layer can be pluggable. But these two projects are in their infancy so
t>>I'll need to speak with Bela about JavaGroups and what API he implemented
t>>for it.
t>>
t>>Bruce
t>
t>
t>JavaGroups looks interesting.
t>
t>So would each JDO (and its associated cache) instance have a uniquely
t>identifiable name for its "Group" in JavaGroups, perhaps IP address +
t>counter (or other id/number that could uniquely identify several JDO
t>instances on the same machine)?
Castor already has the OID object for uniquely identifying objects
within a persistence engine. This would need to be extended to be
globally unique which isn't too difficult.
t>Then, when one JDO instance ("Group") has a value in its cache change,
t>notify the other JDO instances via JavaGroups?
That's somewhat simplified, but it is correct.
t>Also, I asked in a previous post, but has any thought been given to
t>releasing 1.0 of Castor and then working on the clustering/distributed
t>cache for version 2.0? Even though Castor is perhaps one of the oldest
t>object-relational mapping frameworks around, some may be hesitant to use it
t>given that it has never reached "1.0" status. It's probably more
t>psychological than anything else... ;)
Yes, I tend to agree with you that 1.0 needs to be released. I need to
speak with Keith about this. Actually all the refactoring will be checked
into another tag/branch in CVS so as to not affect the current mailine.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
