cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Hjortsberg">
Subject Re: Docs and some questions
Date Wed, 15 Nov 2006 16:22:43 GMT
  That is probably the way to  go. I have been looking at bit at the project.
  To whom it may concern
  From: Andrus Adamchik []
Sent: Wed, 15 Nov 2006 15:50:13 +0100
Subject: Re: Docs and some questions

Looks like you need to synchronize local databases rather than  
  DataContexts (which would be a secondary concern in this situation).  
  Synchronzing contexts (the default implementation at least) only  
  works if all of them are connected to the same database. I.e. if DC1  
  in APP1 commits its changes and DC2 in APP2 receives an event for  
  this commit, DC2 will refresh its objects, but will not mark them as  
  dirty (as it assumes that they are already committed), so even if you  
  commit DC2 after the event is processed, it won't save anything to  
  the DB.
  You will need to investigate what clustering options exist for the DB  
  that you are using. IIRC there was a JavaGroups based solution for  
  On Nov 13, 2006, at 1:32 PM, Andreas Hjortsberg wrote:
  > Hello and thank you all for your replies.
  > Yes, you are correct Andrus, my intentions are to use an ordinary  
  > dataContext, and the reason is that my application must be able to  
  > work offline.
  > I looked through the code regarding JavaGroupBridge and it seems to  
  > me that it is a quite straight forwarard to
  > get two or more  applications to talk to each other over a local  
  > network, and the different datacontext will be updated etc..
  > The more diffucult thing to implement will be to add some logic to  
  > commit the changes on the remote dataContexts to
  > their local databases.
  > In the perfect world I don't need to care about it, because the  
  > remote context  will be updated, and next time someone commit the  
  > changes on their
  > datacontext the local database will update on a correct manner, but  
  > if a user refresh the data before it comes comitted I
  > will lose the changes to this datacontext.
  > Now to my question; where should any of you add this logic? One  
  > could make sure that the client application always commits changes  
  > before he does
  > anything. It does not feel like a good solution, though. Another  
  > approch would be to add another static datacontext for the  
  > application, which will commit after any event has been received  
  > through the JavaGroupBridge?
  > Regards
  > /Andreas
  >> As Ari just mentioned, JGroups site is located here:
  >> Cayenne has built in support for using JGroups as a provider for
  >> cache synchronization. You can configure it in the Modeler:
  >> * Check "Remote Change Notifications" for the DataDomain
  >> * Click the "Configure" button next to it and enter the settings that
  >> you need (or leave the defaults).
  >> And of course you can use JavaGroupsBridge for your own custom
  >> messaging if you need functionality beyond just cache  
  >> synchronization.
  >> Andrus
  >> On Nov 11, 2006, at 9:15 AM, Andreas Hjortsberg wrote:
  >>> Hello,
  >>> In  the api docs for
  >>> there is an invalid link for an example file. I think it's Filip's
  >>> son who shows up, very cute though.
  >>> Is there anyone who knows where I can find another example?
  >>> I'm about to start a project where all clients will have a local
  >>> swing application and database, probably derby or hsqldb.
  >>> It is very important what then a client change some of his objects
  >>> it is broad casted over the local subnet and the other clients will
  >>> be updated and it also notifies a main server.
  >>> Has anyone used cayenne and jgroups for this? Is it the path to
  >>> take? I have looked around but have not found any example or
  >>> comments on this. Or is the existing integration between jgroups
  >>> and cayenne designed to mainly work between instances on a  web
  >>> application?
  >>> Regards
  >>> /Andreas
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message