Re: new EOObjectStoreCoordinator and closing database connection afterwards
OK, I see the reaper Thread logic now and since restart is hard- coded to false, then I guess it does kill connections if free after a time limit default is 600 seconds. The reaper thread runs the reap logic every 20 seconds or so... ok, I will give the connection broker a try .. I think it is definitely suited to the nature of this app. Thanks On Nov 13, 2009, at 9:07 AM, Anjo Krank wrote: Not sure about that. There *are* several things you can tweak, there is also a reap method. No idea when it's called though. Cheers, Anjo Am 13.11.2009 um 13:59 schrieb Kieran Kelleher: BTW, I do like the ConnectionBroker and it might be ideal for this app to ensure connections are used efficiently, but in its current design, if I am not mistaken, it appears to keep connections open forever once opened, so it could do more harm than good in a peak user activity situation. ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: new EOObjectStoreCoordinator and closing database connection afterwards
Not sure about that. There *are* several things you can tweak, there is also a reap method. No idea when it's called though. Cheers, Anjo Am 13.11.2009 um 13:59 schrieb Kieran Kelleher: BTW, I do like the ConnectionBroker and it might be ideal for this app to ensure connections are used efficiently, but in its current design, if I am not mistaken, it appears to keep connections open forever once opened, so it could do more harm than good in a peak user activity situation. ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: new EOObjectStoreCoordinator and closing database connection afterwards
With this particular app, where "Direct Mail Advertizing" services are provided to about 3000 customers, there is a lot of editing/saving by all users and a *lot* of background thread processes invoked by user actions, for example activities such as performing US Postal Hygiene (CASS/DPV/NCOA) processing on user lists. These tasks may last 30 seconds or up to 10 minutes. The long request logs of the useful ERXStatisticsStore clearly show that these background processes can slow down other user EOF activity in regular requests. So these OSCs are short-lived. I have seen connections rise to about 140 during days where many of the activity involved these data processing tasks ... however these are typically *left over idle connections* that did not get closed by the normal OSC.dispose() at the end of the background task. Hence the motivation of this thread because I want to create OSC, use it for a while, and then dispose of it ensuring no residual connections, not because I have seen any memory problems, because I haven't, but because I don't want to hit the max connections limit variable on my database which, when I did one time last week, caused a little bit of havoc for a few users. So, rest assured, I am still only using one default OSC per instance (not even using the ERXOSC pool) for regular requests and I am creating short-lived OSC's for the frequent intense EOF editing/save and I have not run out of memory in an instance in over a year, thanks to ERXFetchSpecificationBatchIterator and in extreme cases, ERXEOAccessUtilities.ChannelAction! BTW, I do like the ConnectionBroker and it might be ideal for this app to ensure connections are used efficiently, but in its current design, if I am not mistaken, it appears to keep connections open forever once opened, so it could do more harm than good in a peak user activity situation. Thanks for saying "it" Anjo! The good advice and genuine interest in the success of others is one of the best things about this community :-) Cheers, Kieran On Nov 13, 2009, at 12:31 AM, Anjo Krank wrote: Just to say it: I think 100 should not be used in production. Your mem usage will go through the roof and your performance way down. 5 or so should be more like it. Cheers, Anjo Am 13.11.2009 um 00:14 schrieb Kieran Kelleher: (I also set the .DBMaxConnections = 100 since docs and source seemed to differ, but I did not spend time figuring out if only one of these or both worked. ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com This email sent to kieran_li...@mac.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: new EOObjectStoreCoordinator and closing database connection afterwards
Just to say it: I think 100 should not be used in production. Your mem usage will go through the roof and your performance way down. 5 or so should be more like it. Cheers, Anjo Am 13.11.2009 um 00:14 schrieb Kieran Kelleher: > (I also set the .DBMaxConnections = 100 since docs and source > seemed to differ, but I did not spend time figuring out if only one of these > or both worked. > ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: new EOObjectStoreCoordinator and closing database connection afterwards
I think this was for FrontBase. Cheers, Anjo Am 13.11.2009 um 00:14 schrieb Kieran Kelleher: > This other related property did not work at all and while mysql indicated > that connections were actually made, EOF failed to return any data when the > readonly SELECTs were tried, so I would not try and make the readonly > switching used by default . this is still "experimental" ;-) > ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: new EOObjectStoreCoordinator and closing database connection afterwards
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
C
Re: new EOObjectStoreCoordinator and closing database connection afterwards
"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 b
Re: new EOObjectStoreCoordinator and closing database connection afterwards
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...@yy on zzz 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...@yy on zzz 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
Re: new EOObjectStoreCoordinator and closing database connection afterwards
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 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...@yy on zzz >>> 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...@yy on zzz >>> 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_
Re: new EOObjectStoreCoordinator and closing database connection afterwards
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. 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...@yy on zzz 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...@yy on zzz 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 parentObject
Re: new EOObjectStoreCoordinator and closing database connection afterwards
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 [EMAIL PROTECTED] on zzz
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 [EMAIL PROTECTED] on zzz
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 (Webobjects-dev@lists.apple.com)
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 fat
Re: new EOObjectStoreCoordinator and closing database connection afterwards
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 [EMAIL PROTECTED] on zzz
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 [EMAIL PROTECTED] on zzz
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.
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 (Webobjects-dev@lists.apple.com)
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
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@list
Re: new EOObjectStoreCoordinator and closing database connection afterwards
On Jul 2, 2008, at 5:34 PM, Mike Schrag wrote: 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. When I read last description, I now retract my previous claim that I don't think jdbc2Info is his problem ... My money is on Chuck -- I'm voting that he's right. What?!!? There was doubt??? -- 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
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. When I read last description, I now retract my previous claim that I don't think jdbc2Info is his problem ... My money is on Chuck -- I'm voting that he's right. ms ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
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.
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 (Webobjects-dev@lists.apple.com)
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
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
On Jul 1, 2008, at 10:05 PM, Lon Varscsak wrote: This is the connection I assumed wasn't closing, but Klaus would have to chime in. I'm using: new ERXEC(new ERXObjectStoreCoordinator(true)); in one specific instance and calling dispose() when I'm done (on the OSC) seems to do the trick (closes both connections properly). MMh, I need to look at dispose again. I tried hat and it does nothing at the database and gives me a null pointer exception after I fall through the bottom of the request response (ie. the log out page). I pointed Klause to ERXEOAccessUtilities.closeDatabaseConnections which is what I believe does the trickery (called from OSC's dispose method). Thanks. (You saw I already do that.) But maybe I misunderstood the problem. :) The actual issue is that with the code I have I accumulate database connections. Every session opens two connections but closes only one when the session terminates. After two sessions terminate I have two connections to the database that are not needed. The connections won't be closed until I quit the instance. Leaving this in the application class and round robin the connection is a wiser choice since that would not kill my database with a spike in sessions or when sessions don't terminate... I'll do more digging in WOnder to see how that's done sigh, I so need to rewrite my app... but that's another story. Thanks all. 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
I missed the beginning of the thread but closing all your connections
is not that difficult...
for (Enumeration stores =
EOObjectStoreCoordinator.defaultCoordinator().cooperatingObjectStores
().objectEnumerator(); e.hasMoreElements();) {
for (Enumeration channels = ((EODatabaseContext)
stores.nextElement()).adaptorContext().channels().objectEnumerator();
channels.hasMoreElements();) {
EOAdaptorChannel channel = (EOAdaptorChannel)
channels.nextElement();
if (channel.isOpen()) {
channel.closeChannel();
}
}
}
Alan
On Jul 1, 2008, at 11:06 PM, Lon Varscsak wrote:
I should add that I'm using WOnder, however, so there may be other
trickery involved that I didn't notice. :)
Lon
On Tue, Jul 1, 2008 at 10:05 PM, Lon Varscsak
<[EMAIL PROTECTED]> wrote:
This is the connection I assumed wasn't closing, but Klaus would
have to chime in. I'm using:
new ERXEC(new ERXObjectStoreCoordinator(true));
in one specific instance and calling dispose() when I'm done (on
the OSC) seems to do the trick (closes both connections properly).
I pointed Klause to ERXEOAccessUtilities.closeDatabaseConnections
which is what I believe does the trickery (called from OSC's
dispose method).
But maybe I misunderstood the problem. :)
Lon
On Tue, Jul 1, 2008 at 9:41 PM, Mike Schrag
<[EMAIL PROTECTED]> wrote:
I would look at Wonder source and see what trickery is being
used to implement this fix.
>>>
>>> I don't think we close ... The OSC pool in Wonder is designed
to be round-robin'ed across requests and never needs to close.
>>
>> I recall a discussion from a while ago that actually getting EOF
to close the connection is difficult / impossible. I have never
needed to (see Mike's comment above), so I have never looked into it.
>
> Maybe you're referring to the jdbc2Info connection? It's not
impossible, but it is very tricky. I don't THINK this is his
problem here, though.
>
> ms
>
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/varscsak%
40smarthealth.com
>
> This email sent to [EMAIL PROTECTED]
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/award%
40apple.com
This email sent to [EMAIL PROTECTED]
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
I'm going to retract everything I've said...cuz I'm dumb. =P I see Klaus is already calling the code in ERXEOAccessUtilities.closeDatabaseConnection so that's not it. I'll keep my yapper shut now. Lon On Tue, Jul 1, 2008 at 10:06 PM, Lon Varscsak <[EMAIL PROTECTED]> wrote: > I should add that I'm using WOnder, however, so there may be other trickery > involved that I didn't notice. :) > Lon > > > On Tue, Jul 1, 2008 at 10:05 PM, Lon Varscsak <[EMAIL PROTECTED]> > wrote: > >> This is the connection I assumed wasn't closing, but Klaus would have to >> chime in. I'm using: >> new ERXEC(new ERXObjectStoreCoordinator(true)); >> >> in one specific instance and calling dispose() when I'm done (on the OSC) >> seems to do the trick (closes both connections properly). >> >> I pointed Klause to ERXEOAccessUtilities.closeDatabaseConnections which >> is what I believe does the trickery (called from OSC's dispose method). >> >> But maybe I misunderstood the problem. :) >> >> Lon >> >> On Tue, Jul 1, 2008 at 9:41 PM, Mike Schrag <[EMAIL PROTECTED]> >> wrote: >> >> I would look at Wonder source and see what trickery is being used to >> implement this fix. >> >>> >> >>> I don't think we close ... The OSC pool in Wonder is designed to be >> round-robin'ed across requests and never needs to close. >> >> >> >> I recall a discussion from a while ago that actually getting EOF to >> close the connection is difficult / impossible. I have never needed to (see >> Mike's comment above), so I have never looked into it. >> > >> > Maybe you're referring to the jdbc2Info connection? It's not >> impossible, but it is very tricky. I don't THINK this is his problem here, >> though. >> > >> > ms >> > >> > ___ >> > Do not post admin requests to the list. They will be ignored. >> > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> > Help/Unsubscribe/Update your Subscription: >> > >> http://lists.apple.com/mailman/options/webobjects-dev/varscsak%40smarthealth.com >> > >> > This email sent to [EMAIL PROTECTED] >> >> > ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
I should add that I'm using WOnder, however, so there may be other trickery involved that I didn't notice. :) Lon On Tue, Jul 1, 2008 at 10:05 PM, Lon Varscsak <[EMAIL PROTECTED]> wrote: > This is the connection I assumed wasn't closing, but Klaus would have to > chime in. I'm using: > new ERXEC(new ERXObjectStoreCoordinator(true)); > > in one specific instance and calling dispose() when I'm done (on the OSC) > seems to do the trick (closes both connections properly). > > I pointed Klause to ERXEOAccessUtilities.closeDatabaseConnections which is > what I believe does the trickery (called from OSC's dispose method). > > But maybe I misunderstood the problem. :) > > Lon > > On Tue, Jul 1, 2008 at 9:41 PM, Mike Schrag <[EMAIL PROTECTED]> > wrote: > > I would look at Wonder source and see what trickery is being used to > implement this fix. > >>> > >>> I don't think we close ... The OSC pool in Wonder is designed to be > round-robin'ed across requests and never needs to close. > >> > >> I recall a discussion from a while ago that actually getting EOF to > close the connection is difficult / impossible. I have never needed to (see > Mike's comment above), so I have never looked into it. > > > > Maybe you're referring to the jdbc2Info connection? It's not impossible, > but it is very tricky. I don't THINK this is his problem here, though. > > > > ms > > > > ___ > > Do not post admin requests to the list. They will be ignored. > > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > > > http://lists.apple.com/mailman/options/webobjects-dev/varscsak%40smarthealth.com > > > > This email sent to [EMAIL PROTECTED] > > ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
This is the connection I assumed wasn't closing, but Klaus would have to chime in. I'm using: new ERXEC(new ERXObjectStoreCoordinator(true)); in one specific instance and calling dispose() when I'm done (on the OSC) seems to do the trick (closes both connections properly). I pointed Klause to ERXEOAccessUtilities.closeDatabaseConnections which is what I believe does the trickery (called from OSC's dispose method). But maybe I misunderstood the problem. :) Lon On Tue, Jul 1, 2008 at 9:41 PM, Mike Schrag <[EMAIL PROTECTED]> wrote: I would look at Wonder source and see what trickery is being used to implement this fix. >>> >>> I don't think we close ... The OSC pool in Wonder is designed to be round-robin'ed across requests and never needs to close. >> >> I recall a discussion from a while ago that actually getting EOF to close the connection is difficult / impossible. I have never needed to (see Mike's comment above), so I have never looked into it. > > Maybe you're referring to the jdbc2Info connection? It's not impossible, but it is very tricky. I don't THINK this is his problem here, though. > > ms > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/varscsak%40smarthealth.com > > This email sent to [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
On Jul 1, 2008, at 9:41 PM, Mike Schrag wrote: I would look at Wonder source and see what trickery is being used to implement this fix. I don't think we close ... The OSC pool in Wonder is designed to be round-robin'ed across requests and never needs to close. I recall a discussion from a while ago that actually getting EOF to close the connection is difficult / impossible. I have never needed to (see Mike's comment above), so I have never looked into it. Maybe you're referring to the jdbc2Info connection? It's not impossible, but it is very tricky. I don't THINK this is his problem here, though. Yeah, that is probably what I am remembering. Mike's very tricky == impossible for most people. ;-) Chuck -- 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
I would look at Wonder source and see what trickery is being used to implement this fix. I don't think we close ... The OSC pool in Wonder is designed to be round-robin'ed across requests and never needs to close. I recall a discussion from a while ago that actually getting EOF to close the connection is difficult / impossible. I have never needed to (see Mike's comment above), so I have never looked into it. Maybe you're referring to the jdbc2Info connection? It's not impossible, but it is very tricky. I don't THINK this is his problem here, though. ms ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
On Jul 1, 2008, at 9:33 PM, Mike Schrag wrote: I would look at Wonder source and see what trickery is being used to implement this fix. I don't think we close ... The OSC pool in Wonder is designed to be round-robin'ed across requests and never needs to close. I recall a discussion from a while ago that actually getting EOF to close the connection is difficult / impossible. I have never needed to (see Mike's comment above), so I have never looked into it. Chuck -- 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
I would look at Wonder source and see what trickery is being used to implement this fix. I don't think we close ... The OSC pool in Wonder is designed to be round-robin'ed across requests and never needs to close. ms ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: new EOObjectStoreCoordinator and closing database connection afterwards
I would look at Wonder source and see what trickery is being used to
implement this fix.
Lon
On Tue, Jul 1, 2008 at 2:41 PM, Klaus Berkling <[EMAIL PROTECTED]> 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.
>
> 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 (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
>
> http://lists.apple.com/mailman/options/webobjects-dev/varscsak%40smarthealth.com
>
> This email sent to [EMAIL PROTECTED]
>
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
new EOObjectStoreCoordinator and closing database connection afterwards
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.
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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
