| Yes, JGroups (http://www.jgroups.org) it really was so painless. It worked right out of the box. I linked the framework, copied the properties information, added a groupName and the entity that I wanted to synchronize. It was fun watching the logs on my development box. If I touched the entity I could watch the update happen. Really slick.
I had it running for three years on a production server and never had a hiccup!
I seem to remember that I even had a conversation with Bela Ban (the author of JGroups), he helped with some of the xml settings as I wanted to update my version of JGoups and he had removed some of the methods that were deprecated when Wonders version was created. I see he has a version 4 alpha now. I think I will wait a while before jumping on that update.
Ted
On Sep 4, 2016, at 4:53 PM, Ricardo Parada < email@hidden> wrote:
Thank you Ted for that link. I was actually present at that presentation.
At that time I did not have a need for synchronization between EOF stacks. I was also overwhelmed by the xml configuration file but now that I hear it again it sounds like there is no need to mess with it. I like that he said that he had used that for years and was never able to deadlock it during extensive testing and that the caches were accurate. That is good.
I did try to use the ERXObjectStoreCoordinatorPool in the past. However for our background threads that are spawned to do work I wanted to make sure that they had a separate pool so that they did not interfere with the foreground threads processing requests from the user. I also wanted connections to the database closed when an object store coordinator was returned to the pool by all the thread(s) using it. That created a better experience and conserved resources.
The synchronization though, it does look like it will solve my problem. I definitely want to play with that. I assume that you are using the second synchronizer based on JBoss stuff, right? Mike mentioned that he would not use the first one for production.
Thank you. On Sep 3, 2016, at 11:44 PM, Theodore Petrosky < email@hidden> wrote: Mike Schrag gave a talk on this.
take a listen to the section at around 19 minutes in. I reread your original post, and I think this IS what you are looking for.
again jmo!
On Sep 3, 2016, at 5:11 PM, Ricardo Parada < email@hidden> wrote:
Thanks Aaron that is a great suggestion. I will give that a try as it does not require messing with snapshots and getting down to lower layers of EOF. I think I would feel better with an implementation like that.
As for ERXJGroupsSynchronizer, I am not familiar with that and can't really tell how to use it. It also sounds like it might replace edits in progress. Thanks Ted. I had heard of this class before but did not know it was being used successfully. It is good to know. On Sep 3, 2016, at 4:45 PM, Aaron Rosenzweig < email@hidden> wrote: Hi Ricardo,
That’s some clever WO-ninja magic you got going on there. I’ve never replaced the original snapshot of an EO before.
If it works, great - I won’t knock it but I’d be scared without flexing it (using it a bunch).
Another idea…
1) hold onto the “changesFromCommittedSnapshot” so you can refer to it.
2) in your fetchSpec make “setRefereshesRefetchedObjects()” to true - so when you go round trip you’ll update the EO.
3) reapply your changes from the committed snapshot.
Cheers,
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|