At 13:22 03/05/30 -0500, you wrote:
>
> So would each JDO (and its associated cache) instance have a uniquely
> identifiable name for its "Group" in JavaGroups, perhaps IP address +
> counter (or other id/number that could uniquely identify several JDO
> instances on the same machine)?

I'm not even sure the individual names matter in this case. You'd just
broadcast the message to invalidate a given object. Any Castor JDO
instance listening in on a particular group-channel would then honor the
request and send an acknowledgement.

Thanks for explaining how JavaGroups works. Just registering the JDO to JavaGroup sounds fairly straight forward. Just trying to get a picture of how clustering can be implemented in Castor... So each JDO would fire off a "CacheEvent" (types could be OBJECT_ADDED, OBJECT_MODIFIED_, OBJECT_REMOVED) to JavaGroups, and each JDO's "CacheListener" would be registered with JavaGroups and listen for "CacheEvent"s, and update their local cache appropriately, depending on the CacheEvent?



Yes. Once we hit Castor 0.9.6 we'll be on the fast track to 1.0. My goal
is for 0.9.7->1.0 to be only bug fixes, additional test cases, and
documentation. No feature develepmont. 0.9.6 will be the last release
with new features, which is why we're moving slowly to that point
because there are still features we're trying to finish up.

Actually we're ready to do a new release, so hopefully I'll find the
time this weekend to do it.

So is the next release (possibly this weekend) 0.9.6, skipping 0.9.5? If so, then could bug fixes for 0.9.6 be wrapped up and released as 1.0? Bug fixes could always be released as 1.0.1, 1.0.2, etc. Again, 1.0 milestone is a big psychological mark, especially since the Castor releases are not as frequent (i.e. monthly, roughly the case with JBoss). I noticed in a previous article that someone mentioned Castor never having released 1.0 despite it being around for a while. Releasing 1.0 will definitely give Castor a better image, that it is capable of production use. Are there any major outstanding bugs preventing a sooner 1.0 release?


I believe that a lot of people had a problem with ObjectModifiedException because no "count-limited" attribute value was specified for the Class <cache-type> element and the default was broken? I also had a minor problem with a read-only Class, but I have to dive into the details of that again...

Other than that, are there are real Castor killers?

Overall, Castor is a great product and is greatly appreciated!

----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev




Reply via email to