Re: new EOObjectStoreCoordinator and closing database connection afterwards
Re: new EOObjectStoreCoordinator and closing database connection afterwards
- Subject: Re: new EOObjectStoreCoordinator and closing database connection afterwards
- From: Johan Henselmans <email@hidden>
- Date: Thu, 12 Nov 2009 11:47:17 +0100
Op 12 nov 2009, om 03:06 heeft Kieran Kelleher het volgende geschreven:
> OK, if Jeff Schmitz is going to resurrect an old thread today, then so am I ;-)
>
> OK, I use Wonder (like driving with a seatbelt on) ... anyhow, I use ERXObjectStoreCoordinator exclusively (even for the default OSC) and I can confirm that each time I open a new ERXOSC (passing true - to close conns on dispose - in the boolean param constructor), two connections are created. Then when I dispose, one is closed and the other is left open.
>
I had something similar on a test machine: everytime I connected to the testsite, two connections were opened extra. I tried using just one EOEditingcontext (in Application) just to see if it might have something to do with each session creating its own connection. (On using only one editing context: it's read-only information)
Has it something to do with running the project from Eclipse?
> In this example, connection id's 3 and 4 are created as follows:
>
> 3 Connect w3b0bj3cts@localhost on cheetah
> 3 Query SHOW SESSION VARIABLES
> 3 Query SHOW COLLATION
> 3 Query SET character_set_results = NULL
> 3 Query SET autocommit=1
> 3 Query SET sql_mode='STRICT_ALL_TABLES,STRICT_TRANS_TABLES'
> 3 Query SELECT @@session.tx_isolation
> 3 Query SET autocommit=0
> 4 Connect w3b0bj3cts@localhost on cheetah
> 4 Query SHOW SESSION VARIABLES
> 4 Query SHOW COLLATION
> 4 Query SET character_set_results = NULL
> 4 Query SET autocommit=1
> 4 Query SET sql_mode='STRICT_ALL_TABLES,STRICT_TRANS_TABLES'
> 4 Query SELECT @@session.tx_isolation
> 4 Query SET autocommit=0
>
> Connection #3 is the one that is actually used by EOF throughout EOF operations during the life of the ERXOSC.
>
> After using the OSC and calling dispose, #3 gets closed by ERXOSC and #4 remains.
>
> The statements above are identical when both connections are opened, and the ones shown for #4 are all there is for #4.... not another single statement.
>
> Any thoughts on how we can get both connections closed when the ERXOSC is disposed of?
>
> Regards, Kieran
>
>
>
> On Jul 7, 2008, at 6:12 PM, Chuck Hill wrote:
>
>>
>> On Jul 7, 2008, at 2:38 PM, Klaus Berkling wrote:
>>
>>>
>>> On Jul 2, 2008, at 4:50 PM, Chuck Hill wrote:
>>>
>>>>
>>>> On Jul 1, 2008, at 2:41 PM, Klaus Berkling wrote:
>>>>
>>>>> Hi all.
>>>>>
>>>>> In my application I'm trying to use independent access layer stacks to open multiple database connections to the database.
>>>>> I use this code:
>>>>>
>>>>> EOObjectStoreCoordinator parentObjectStore = new EOObjectStoreCoordinator();
>>>>> EOEditingContext editingContext = new EOEditingContext(parentObjectStore);
>>>>> setDefaultEditingContext(editingContext);
>>>>>
>>>>> This looks like it's working in that it opens two new connection to the database when I start a new session. As expected.
>>>>
>>>> If it is opening two, I'd expect one to be to get the JDBC2 Info and the other for EOF to use to fetch data. As Mike noted earlier, getting EOF to close the JDBC 2 Info connection is tricky. Can you get the DB to log what is sent over each connection? That should indicate if I am right or not.
>>>
>>>
>>> This is what shows up in the mysql log when my client connects:
>>>
>>> 080707 14:27:10 67 Connect xxxxx@yyyyyy on zzzzzzz
>>> 67 Query SET NAMES latin1
>>> 67 Query SET character_set_results = NULL
>>> 67 Query SHOW VARIABLES
>>> 67 Query SHOW COLLATION
>>> 67 Query SET autocommit=1
>>> 67 Query SHOW VARIABLES LIKE 'tx_isolation'
>>> 67 Query SET autocommit=0
>>> 68 Connect xxxxx@yyyyyy on zzzzzzz
>>> 68 Query SET NAMES latin1
>>> 68 Query SET character_set_results = NULL
>>> 68 Query SHOW VARIABLES
>>> 68 Query SHOW COLLATION
>>> 68 Query SET autocommit=1
>>> 68 Query SHOW VARIABLES LIKE 'tx_isolation'
>>> 68 Query SET autocommit=0
>>>
>>> At logout from the client:
>>>
>>> 080707 14:27:16 67 Prepare [25] UPDATE RS_USER_SESSION SET LOUT_TIME = ? WHERE (USER_SESSION_PK = ? AND LOGIN_GROUP_NUM = ? AND LOGIN_STUDENT_PK is NULL)
>>> 67 Execute [25] UPDATE RS_USER_SESSION SET LOUT_TIME = '2008-07-07 14:30:06' WHERE (USER_SESSION_PK = '558446' AND LOGIN_GROUP_NUM = '1' AND LOGIN_STUDENT_PK is NULL)
>>> 67 Query commit
>>> 67 Query rollback
>>> 67 Quit
>>>
>>> There never is a Quit from 68.
>>
>> It is hard to say from that, the jcbc2info request might not get logged like this. But my money is still on the jdbc2info connection. It fits all of the evidence.
>>
>> Mike figured out how to close it, but I don't know where the code is in Wonder. Hmmm, that might have been in Entity Modeler.
>>
>> Mike?
>>
>>
>> Chuck
>>
>>
>>>>> When I'm terminate the session I use this code to close the connection to the database:
>>>>>
>>>>> 'editingContext' is the session 'defaultEditingContext()'
>>>>>
>>>>> EOObjectStoreCoordinator parentObjectStore = (EOObjectStoreCoordinator)(editingContext.parentObjectStore());
>>>>> NSArray databaseContexts = parentObjectStore.cooperatingObjectStores();
>>>>> int contextCount = databaseContexts.count();
>>>>>
>>>>> for (int i = 0; i < contextCount; i++) {
>>>>> NSArray channels = ((EODatabaseContext)databaseContexts.objectAtIndex(i)).registeredChannels();
>>>>> int channelCount = channels.count();
>>>>> for (int j = 0; j < channelCount; j++) {
>>>>> //Make sure the channel you're trying to close isn't performing a transaction.
>>>>> if (!((EODatabaseChannel)channels.objectAtIndex(j)).adaptorChannel().adaptorContext().hasOpenTransaction()) {
>>>>> ((EODatabaseChannel)channels.objectAtIndex(j)).adaptorChannel().closeChannel();
>>>>> }
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>> This closes one of the two database connection, not both.
>>>>>
>>>>> Is there a way to detect the one extra connection or not open the extra connection in the first place?
>>>>>
>>>>> WOnder may have resolved this issue but adding WOnder is a bigger undertaking then I originally expected.
>>>>> Paraphrasing Lou Reed, I just want some of it, not all of it.
>>>>>
>>>>> Thanks
>>>>>
>>>>> kib
>>>>>
>>>>> "Success is not final, failure is not fatal: it is the courage to continue that counts.”
>>>>> - Winston Churchill
>>>>>
>>>>> Klaus Berkling
>>>>> Systems Administrator
>>>>> DynEd International, Inc.
>>>>> www.dyned.com | www.eskimo.com/~kiberkli
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> --
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> Thanks
>>>
>>> kib
>>>
>>> "Success is not final, failure is not fatal: it is the courage to continue that counts.”
>>> - Winston Churchill
>>>
>>> Klaus Berkling
>>> Systems Administrator
>>> DynEd International, Inc.
>>> www.dyned.com | www.eskimo.com/~kiberkli
>>>
>>>
>>>
>>>
>>>
>>
>> --
>>
>> 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
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
Regards,
Johan Henselmans
http://www.netsense.nl
Tel: +31-20-6267538
Fax: +31-20-6279159
_______________________________________________
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