Re: Database Connection Question
Re: Database Connection Question
- Subject: Re: Database Connection Question
- From: Chuck Hill <email@hidden>
- Date: Tue, 23 Nov 2010 15:09:50 -0800
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@hidden>:
>> 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@hidden>:
>>>>
>>>> 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden