search

uncopenweb / torongo

Utilities for using Mongo with Tornado.
6 stars 1 forks source link

Multiple local MongoStores do not reflect underlying collection changes #17

Open parente opened 13 years ago

parente commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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.