"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 w3b0bj3...@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 w3b0bj3...@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 xx...@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 xx...@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 protected])
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>>>>>>>
>>>>>>> This email sent to [email protected]
>>>>>>
>>>>>> --
>>>>>>
>>>>>> 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 protected])
>>>> Help/Unsubscribe/Update your Subscription:
>>>> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com
>>>>
>>>> This email sent to [email protected]
>>>
>>> _______________________________________________
>>> 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/chill%40global-village.net
>>>
>>> This email sent to [email protected]
>>
>> --
>> 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 protected])
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
>>
>> This email sent to [email protected]
>
> _______________________________________________
> 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/anjo%40krank.net
>
> This email sent to [email protected]
_______________________________________________
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]
