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: Mike Schrag <email@hidden>
- Date: Thu, 12 Nov 2009 16:49:58 -0500
Yeah i was thinking we should should default this as well. I can't think of a reason, offhand, to not want this all the time.
ms
On Nov 12, 2009, at 4:42 PM, Anjo Krank wrote:
> "Hacky"... what a strange word.
>
>> # er.extensions.ERXJDBCAdaptor.className=er.extensions.jdbc.ERXJDBCAdaptor
>
> I think we can set this as the default further on. In particular as this also fixes the §$% SQL-Error-messes-up-DBCs issues.
>
> Cheers, Anjo
>
>
>
> Am 12.11.2009 um 20:10 schrieb Mike Schrag:
>
>> I would add a stack trace into dataBaseChannelNeeded in ERXAdaptorChannelDelegate to get the stack of exactly where it's called ... my first thought was jdbc2Info, too, but I thought I fixed this a couple years ago.
>>
>> Ah .. That's done in ERXJDBCAdaptor, which is only used if you explicitly set it:
>>
>> ## Class name to use instead of the JDBCAdaptor, the ERXJDBCAdaptor supports
>> ## connection pooling
>> # er.extensions.ERXJDBCAdaptor.className=er.extensions.jdbc.ERXJDBCAdaptor
>>
>> See if that does anything for you. The fix for closing that connection is REALLY hacky. My favorite part is how I didn't put a SINGLE comment on the code that does it. Old me hated future me, though.
>>
>>> protected JDBCContext _cachedAdaptorContext() {
>>> if (_cachedContext == null) {
>>> _cachedContext = createJDBCContext();
>>> }
>>> return _cachedContext;
>>> }
>>>
>>> protected NSDictionary jdbcInfo() {
>>> boolean closeCachedContext = (_cachedContext == null && _jdbcInfo == null);
>>> NSDictionary jdbcInfo = super.jdbcInfo();
>>> if (closeCachedContext && _cachedContext != null) {
>>> _cachedContext.disconnect();
>>> _cachedContext = null;
>>> }
>>> return jdbcInfo;
>>> }
>>>
>>> protected NSDictionary typeInfo() {
>>> boolean closeCachedContext = (_cachedContext == null && _jdbcInfo == null);
>>> NSDictionary typeInfo = super.typeInfo();
>>> if (closeCachedContext && _cachedContext != null) {
>>> _cachedContext.disconnect();
>>> _cachedContext = null;
>>> }
>>> return typeInfo;
>>> }
>>>
>>> public Context createJDBCContext() {
>>> Context context = new Context(this);
>>> return context;
>>> }
>>>
>>> public EOAdaptorContext createAdaptorContext() {
>>> EOAdaptorContext context;
>>> if (_cachedContext != null) {
>>> context = _cachedContext;
>>> _cachedContext = null;
>>> }
>>> else {
>>> context = createJDBCContext();
>>> }
>>> return context;
>>> }
>>
>> On Nov 12, 2009, at 2:00 PM, Chuck Hill wrote:
>>
>>> On Nov 11, 2009, at 6:06 PM, Kieran Kelleher wrote:
>>>
>>>> OK, if Jeff Schmitz is going to resurrect an old thread today, then so am I ;-)
>>>
>>> :-P
>>>
>>>
>>>> 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.
>>>
>>> One connection is expected. The other I would expect to be fetching JDBC2Info data for one or more models lacking this. That connection does not get closed properly by EOF. As I noted before, Mr. Schrag tracked this down and is closing it in some piece of code. Where that code is, I do not know. Mike, you there?
>>>
>>>
>>> Chuck
>>>
>>>
>>>
>>>> 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
>>>
>>> --
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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