Jason, thanks for the reply. The answers to your questions are inline.
> Lemme get this straight first. Both the web and the desktop > would have > their own instances of OJB? That's my impression at this point. > The caching issue somewhat depends on your requirements. If > you're in a > highly "pessimistic" transactional environment, then there > are a couple > of options. You can, as you said, disable caching, or you can set the > systems up to clear the caches regularly. The concept of periodic-cache-clearing requires too much of this bottle of head-ache pills: they allow for the opportunity of non-recreatable timing bugs (user a makes a modification, but user b has to wait for the cache clear to see it). It just leaves a bad taste. > At NACSE, we run OJB in a heavily clustered/failover/load-balanced > environment. To get around the problem that you are encountering > (Caches being out of Synch) we decided to use a clustered/distributed > cache. > > This ensures that the cache structures on different nodes are notified > of changes in the cache structure. However, we are in a carefully > controlled server only environment. I'm not sure if this > would work for > you, since the desktops would have to initialize, and synchronize the > caches (through multicast) every time someone started their > desktop app. I'm interesting in learning more about your environment (the non-proprietary aspects ;-) ). I might be able to learn something that can help my architecture. > Another question: What are the different apps for? For > example: if the > desktop apps are for entering/updating data for the web > system, then why > not disable caching on the desktop? If the web-system is more to > display (more reads than writes) that input data, then it would be a > more logical place for the cache. You can then flush the web > cache, and > update for input changes at the database. Currently, we've limited things to three clients: a network-based service (non-web), a restricted access web-service (exterior of firewall) and a non-restricted web-service (interior of firewall). Now, the non-web service is duplicated on a parallel machine (ok, that's 4 clients). Additionally, we're looking at desktop client (possibly to aid in offloading work from the web-services). Due to the fact that some clients would be outside of a firewall, I'm not sure how much clustering would be able to help me. The web-services and desktop clients allow users to modify / add / remove / control the services that the non-web service provides for them. Both also communicate with the non-web service. > So again, it is likely possible to do what you want. But it > depends on > your requirements. Final requirement that has yet to be mentioned: we are not currently using EJBs for communication between clients / services / etc. Data communication is through the database, data change notifications is through an RMI-broadcasting structure (that I REALLY, REALLY want to get rid of). I guess one of the ancillary things I was looking for was a way for a DB to push information down a JDBC connection, thus allowing the clients to react appropriately to the change of information. If such a thing actually existed, then OJB would/should be using it for cache synch. Does anybody know of any such architecture? > ps. If you're interested in the distributed cache, I think there is a > contrib file somewhere for adding Tangosol Coherence support that I > wrote. With the release this week of OSCache 2.0, I am also > planning on > writing a plug for using OSCache's distributed cache with OJB > (Tangosol > is expensive, OSCache is free). OJB also supports JCS, but I had real > problems with it. > > Jason Thanks for the feedback Jason. It is certainly appreciated. Jay Glanville --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
