Yes, JGroups (http://www.jgroups.org <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 protected]> 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 protected] > <mailto:[email protected]>> wrote: > >> Mike Schrag gave a talk on this. >> >> http://www.wocommunity.org/podcasts/wowodc/west09/WOWODC09W-WonderInDepth.mov >> >> <http://www.wocommunity.org/podcasts/wowodc/west09/WOWODC09W-WonderInDepth.mov> >> >> 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 protected] >>> <mailto:[email protected]>> 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 protected] >>> <mailto:[email protected]>> 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, >>>> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> >>>> e: [email protected] <mailto:[email protected]> t: (301) 956-2319 >>>> >>>> >>>> >>>>> On Sep 3, 2016, at 9:34 AM, Ricardo Parada <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I have a need to refresh the to-one relationship of an object, so that if >>>>> someone in another app or perhaps in a different EOF stack within the >>>>> same app has updated the to-one to point to a different object then I >>>>> want my EO’s to one to point to the correct EO. I do not want to >>>>> invalidate the source EO or refetch it because it may have edits in >>>>> progress. >>>>> >>>>> I searched in Wonder but I was not able to find anything that does this. >>>>> I came up with the code below last night and it seems to work well so >>>>> far. >>>>> >>>>> Since this is an advanced EOF topic I thought I should share it to see if >>>>> anybody wants to code review it, play with it and provide comments on >>>>> correctness / recommendations / feedback. >>>>> >>>>> This code uses a primaryKeyQualifier() method in my EO which is >>>>> practically the same as the identityQualifier() concept discussed by >>>>> Aaron Rosenzweig in an email thread in May of this year. >>>>> >>>>> Thanks in advance for any help. >>>>> >>>>> >>>>> @SuppressWarnings("rawtypes") >>>>> public void refreshToOneRelationshipWithKey(String toOneName) { >>>>> EOEditingContext ec = editingContext(); >>>>> EOEntity entity = entity(); >>>>> EORelationship toOne = entity.relationshipNamed(toOneName); >>>>> String foreignKeyName = >>>>> toOne.sourceAttributes().lastObject().name(); >>>>> EOFetchSpecification fs = new EOFetchSpecification(entity.name(), >>>>> primaryKeyQualifier(), null); >>>>> fs.setRawRowKeyPaths(new NSArray<String>(foreignKeyName)); >>>>> @SuppressWarnings("unchecked") >>>>> NSDictionary<String,Object> dict = (NSDictionary<String,Object>) >>>>> ec.objectsWithFetchSpecification(fs).lastObject(); >>>>> Object newForeignKeyValue = dict.allValues().lastObject(); >>>>> EOGlobalID gid = globalID(); >>>>> EOModel model = entity.model(); >>>>> EODatabaseContext dbc = >>>>> EODatabaseContext.registeredDatabaseContextForModel(model, ec); >>>>> EODatabase database = dbc.database(); >>>>> EOObjectStoreCoordinator osc = (EOObjectStoreCoordinator) >>>>> ec.rootObjectStore(); >>>>> osc.lock(); >>>>> try { >>>>> NSDictionary snapshot = database.snapshotForGlobalID(gid); >>>>> Object currentForeignKeyValue = >>>>> snapshot.objectForKey(foreignKeyName); >>>>> // We don't need to check for null as currentForeignKeyValue >>>>> and newForeignKeyValue >>>>> // use NSKeyValueCoding.NullValue to represent null. >>>>> if (currentForeignKeyValue.equals(newForeignKeyValue) == >>>>> false) { >>>>> NSMutableDictionary newSnapshot = snapshot.mutableClone(); >>>>> newSnapshot.takeValueForKey(newForeignKeyValue, >>>>> foreignKeyName); >>>>> >>>>> database.recordSnapshotForGlobalID(newSnapshot.immutableClone(), gid); >>>>> Object toOneValue = NSKeyValueCoding.NullValue; >>>>> if (newForeignKeyValue != NSKeyValueCoding.NullValue) { >>>>> EOKeyGlobalID toOneGID = >>>>> ERXEOGlobalIDUtilities.createGlobalID(toOne.destinationEntity().name(), >>>>> new Object[] {newForeignKeyValue}); >>>>> toOneValue = ec.faultForGlobalID(toOneGID, ec); >>>>> } >>>>> // Update __originalSnapshot() and EO so that >>>>> changesFromCommittedSnapshot() >>>>> // does not think that the object has changed. >>>>> NSDictionary originalSnapshot = __originalSnapshot(); >>>>> NSMutableDictionary newOriginalSnapshot = >>>>> originalSnapshot.mutableClone(); >>>>> newOriginalSnapshot.setObjectForKey(toOneValue, >>>>> toOneName); >>>>> >>>>> __setOriginalSnapshot(newOriginalSnapshot.immutableClone()); >>>>> if (toOneValue == NSKeyValueCoding.NullValue) { >>>>> takeStoredValueForKey(null, toOneName); >>>>> } else { >>>>> takeStoredValueForKey(toOneValue, toOneName); >>>>> } >>>>> } >>>>> } finally { >>>>> osc.unlock(); >>>>> } >>>>> } >>>>> >>>>> public EOQualifier primaryKeyQualifier() { >>>>> NSDictionary<String, Object> pkDict = primaryKeyDictionary(false >>>>> /* inTransaction */); >>>>> EOEntity entity = entity(); >>>>> return entity.qualifierForPrimaryKey(pkDict); >>>>> } >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list ([email protected] >>>>> <mailto:[email protected]>) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com >>>>> >>>>> <https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com> >>>>> >>>>> This email sent to [email protected] <mailto:[email protected]> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected] >>> <mailto:[email protected]>) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/tedpet5%40yahoo.com >>> <https://lists.apple.com/mailman/options/webobjects-dev/tedpet5%40yahoo.com> >>> >>> This email sent to [email protected] <mailto:[email protected]>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
