On Nov 23, 2010, at 3:01 PM, Gennady Kushnir wrote:

> Hello all
> Thanks for you replies. Looks like I have enough to explore yet.
> 
>> It should not be creating more unless you are creating more EOF stacks in 
>> you code.
> 
> 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.


> 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.  

Joe (Little), weren't you doing something similar?


> 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.


> 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?


Chuck


> In my case I decided to close that AdaptorChannel myself after
> connecting model to database.
> As a result I have no dangling connections after launch. And when an
> app needs data  for some real work it opens new connection that gets
> reused afterwards.
> 
> If anyone interested you may review my code on github:
> https://github.com/baywind/reusables/blob/master/Sources/net/rujel/reusables/DataBaseConnector.java
> Here I am speaking about row 222 and around
> 
> 2010/11/23 Chuck Hill <[email protected]>:
>> Hi,
>> 
>> On Nov 23, 2010, at 1:54 AM, Gennady Kushnir wrote:
>> 
>>> Hello Chuck and others.
>>> I'd like ask some more questions )
>>> 
>>> 2010/8/27 Chuck Hill <[email protected]>:
>>>> 
>>>> On Aug 25, 2010, at 11:10 PM, Dov Rosenberg wrote:
>>>> 
>>>>> I am revisiting some old EOF documentation and wanted to make sure I 
>>>>> understood a few things. Are the following statements true?
>>>>> 
>>>>> 
>>>>> *   When an EOModel is found and connected to a database when the app 
>>>>> starts up each database connection is mapped to an EODatabaseChannel?
>>>> 
>>>> I think that EODatabaseContext is more correct than EODatabaseChannel.  
>>>> The context will then use the channel.  A db context can handle multiple 
>>>> models (the connection information needs to be the same).
>>> 
>>> How can single db context handle multiple models ?
>> 
>> They all need to have the same connection dictionary.  This allows one 
>> database schema to be partitioned between several models.  I could be wrong 
>> too :-)  All the models might be part of the same EODatabase, and each model 
>> gets its own EODatabaseConnection.  I am too lazy to look it up right now.
>> 
>> 
>>> I see that
>>> EODatabaseContext.forceConnectionWithModel(model,cd,ec)
>>> returns different objects for different models, whereas most of my
>>> models point to the same database with the same connection dictionary.
>> 
>> IIRC, that method is not the normal method that EOF uses so the results may 
>> be different than normal.  Also note that the models needs to have the exact 
>> same* (equals()) connection dictionaries.
>> 
>> * OK, they don't need to be fully equals() but the main entries must be 
>> equals().
>> 
>> 
>>> And would it make sense to somehow force all these models to single db 
>>> context?
>> 
>> That depends on the EOF implementation.
>> 
>> 
>>>>> Is there a default number of EODatabaseChannels opened when the app 
>>>>> starts up? Is there a configuration setting that I can set to add more?
>>>> 
>>>> One per db context and no.
>>> My problem is that I see my app opening more connections than a number
>>> of models it has.
>> 
>> That is the jdbc2info connection.  It is an old bug in EOF that this does 
>> not get closed or reused.  The JDBC adaptor in Wonder will close this, but 
>> someone (Simon?) was reporting problems generating PKs with it under load 
>> recently.
>> 
>> 
>>> And those connections do not close even after more than an hour not
>>> used. And it does not reuse all of them for later requests but may
>>> create even more connections.
>> 
>> It should not be creating more unless you are creating more EOF stacks in 
>> you code.
>> 
>> 
>>> As a result when running multiple instances on a server with limited
>>> DB-connections I do get "too many connections" error sometimes.
>>> 
>>> How could I fight it? Is it possible to control the number of open
>>> connections and close unused ones after certain idle time?
>> 
>> Mike said, "this is very tricky".  The code is in, or referenced by, the 
>> JDBC adaptor in Wonder.  I think.
>> 
>> 
>> Chuck
>> 
>> 
>>>> 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
>> 
>> --
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 

-- 
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







Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to