Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple local MongoStores do not reflect underlying collection changes #17

Open
parente opened this issue Oct 3, 2010 · 3 comments
Open

Comments

@parente
Copy link
Member

parente commented Oct 3, 2010

I have two independent widgets. Both do a uow.getDatabase to the same db, collection pair. Both connect to onSet on the data store. When widget #1 updates an item in the collection, it's onSet handler runs, but widget #2's doesn't. The same holds true when widget #2 does the update: widget #1 is not notified.

This breaks our assumption that JsonRestStore instances pointing to the same URL endpoints notify one another of changes. Apparently, they don't.

Tracking (url, mode) -> store pairs and returning existing instances at the uow level or MongoStore level would fix this problem.

@gbishop
Copy link
Member

gbishop commented Oct 3, 2010

I thought for sure they did. In the code they do a lookup on the service to see if it has already been created. I guess they don't connect back at the store level?

@gbishop
Copy link
Member

gbishop commented Oct 3, 2010

Another possibility would be to connect their onSet methods instead of returning the same object. That way even stores with different modes could communicate. I worry a bit about stores being artificially kept alive by any such mechanism resulting in memory leakage.

@parente
Copy link
Member Author

parente commented Oct 3, 2010

Singleton breaks independent queries and thus views. Connect causes memory management issues.

What about pub/sub? MongoStore can subscribe to some private topic that it broadcasts whenever one instance detects a CUD change. Other MongoStore instances could then refresh the current query, invoke the proper callback, whatever they need to do.

Or we can just forget the whole thing and say the instances are not linked in any way. If you make a change in one instance, it's up to you to do a refresh in others. Punt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants