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 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/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/archive%40mail-archive.com
This email sent to [email protected]
