Re: Code review for refreshToOneRelationshipWithKey
Re: Code review for refreshToOneRelationshipWithKey
- Subject: Re: Code review for refreshToOneRelationshipWithKey
- From: Ricardo Parada <email@hidden>
- Date: Tue, 06 Sep 2016 14:29:18 -0400
I just tried the ERJGroupsSynchronizer and it worked. I was worried that there might be a delay in the synchronization such that the thread updating the user interface might not pick up the change on time and would display the new info. I'm curious how it does it and whether it is possible for the change not to get to the user interface on time.
Thanks Paul and Ted. On Sep 4, 2016, at 7:39 PM, Paul Hoadley < email@hidden> wrote: Hi Ricardo, On 5 Sep 2016, at 6:23 AM, Ricardo Parada < email@hidden> wrote:
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.
We’ve been using ERJGroupsSynchronizer.framework in a couple of contexts for at least 12 months, and haven’t seen any issues.
|
_______________________________________________
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