On Nov 24, 2010, at 2:18 AM, Gennady Kushnir wrote: >>> The point is that I do use multiple EOF stacks. I clearly admit that >>> each EOObjectStoreCoordinator gets its own set of db connections. >> >> It only needs a single connection to work. > > Let's say single connection for each used database ;) > In fact that is a goal I'd like to achieve to have a single connection > for a EOF stack per database.
That is what should happen *if* the connection dictionaries are equals() and you close the jdbc2info connections. >>> I use separate EOF stack to access previous year data stored in a >>> separate database with identical structure. >>> That is why I employ >>> EODatabaseContext.forceConnectionWithModel(model,connectionDict,ec) >>> And that is why my models get identical connection dictionary. >> >> I am not sure if that is the best / right way to do this. > > I did not find any other method to connect a model do different databases. You need to create a new model group for the new EOF stack (the one using data from previous years), add the models, and update the connection dictionaries before using the EOF stack. >>> I am quite interested if multiple models could share single db context >>> and thus lower the number of open connections. >> >> They can't share db contexts across EOF stacks. > That's quite clear. I am speaking about several models within one > stack connecting to the same database. > >>> During my experimentations I have found that it is >>> EODatabaseContext.forceConnectionWithModel(...) the one who create a >>> connection for a mentioned model which does not get reused afterwards. >>> May be that is aforementioned JDBCinfo connection? >> >> Maybe or it could be a side effect or misuse of that method. Are the models >> already connected in the new EOF stack before you call this? > No, they are not connected. I call this in Application constructor. > And also this method is the only place where models get correct > connection dictionary. Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
