Created attachment 68086 [details]
stacktrace

Interesting is that db explorer works well with the same connection. Please see more user comments here http://statistics.netbeans.org/analytics/detail.do?
id=86178

Build: NetBeans IDE Dev (Build 200808230201)
VM: Java HotSpot(TM) Client VM, 10.0-b23, Java(TM) SE Runtime Environment, 1.6.0_07-b06
OS: Windows XP, 5.1, x86

User Comments: 


Stacktrace: 
java.lang.IllegalStateException: This connection is not added to the ConnectionManager.
        at org.netbeans.api.db.explorer.ConnectionManager.showConnectionDialog(ConnectionManager.java:338)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:441)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:440)
        at org.openide.util.Mutex$1AWTWorker.run(Mutex.java:1370)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)

Created attachment 68221 [details]
stacktrace

Can you repeat this consistently or only randomly?

so, after I updated a build, the problem disappeared. I will reopen the issue if I find reproducible case

today build and i get this exception:

SEVERE [org.openide.util.RequestProcessor]
java.lang.IllegalStateException: This connection is not added to the ConnectionManager.
        at org.netbeans.api.db.explorer.ConnectionManager.showConnectionDialog(ConnectionManager.java:353)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:441)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:440)
        at org.openide.util.Mutex$1AWTWorker.run(Mutex.java:1370)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:104)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
[catch] at java.awt.EventDispatchThread.run(Unknown Source)

This is mine, I've been encountering this in the unit tests as well.  Andrei backed out a change I made to fix this
because of a P1 regression it caused so not surprisingly this is back.

Can you please tell me: does this happen after you change a property on the connection like the user name or schema?

Build: NetBeans IDE Dev (Build 200809020201)
VM: Java HotSpot(TM) Client VM, 10.0-b23, Java(TM) SE Runtime Environment, 1.6.0_07-b06
OS: Windows XP, 5.1, x86

User Comments: 
Connected to a database and opened a command window.
This occurred when I tried to execute the SQL

Stacktrace: 
java.lang.IllegalStateException: This connection is not added to the ConnectionManager.
        at org.netbeans.api.db.explorer.ConnectionManager.showConnectionDialog(ConnectionManager.java:353)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:441)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:440)
        at org.openide.util.Mutex$1AWTWorker.run(Mutex.java:1370)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)

Created attachment 68987 [details]
stacktrace

Build: NetBeans IDE Dev (Build 200809020201)
VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) SE Runtime Environment, 1.6.0_10-rc-b28
OS: Linux, 2.6.24-19-generic, i386

User Comments: 
1) in Services tab, Databases node:
2) use existing database connection in Services, open SQL Command window
3) close command window, select "Disconnect"
4) change properties of database connection (e.g. database name)
5) connect
6) open command window and enter an SQL command


Stacktrace: 
java.lang.IllegalStateException: This connection is not added to the ConnectionManager.
        at org.netbeans.api.db.explorer.ConnectionManager.showConnectionDialog(ConnectionManager.java:353)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:441)
        at org.netbeans.modules.db.sql.loader.SQLEditorSupport$SQLExecutor$1.run(SQLEditorSupport.java:440)
        at org.openide.util.Mutex$1AWTWorker.run(Mutex.java:1370)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)

Created attachment 69084 [details]
stacktrace

Reproduced.  The problem is that when you change the URL, driver, user name, or schema, of the connection, it's actually
no longer the "same" connection - it points to a different resource (or the same resource with potentially different
rights if you change the user name, which is logically a different resource).

What should happen is that in the SQL editor the selected connection should become empty, because the connection that
was previously selected no longer exists.

I'll see how to do that.

*** Issue 145942 has been marked as a duplicate of this issue. ***

Icky - if you change the URL back to the original, the drop-down in the SQL editor doesn't pick that up - your only
choice is the old (now broken) connection.

Even worse - if you *close* the SQL editor and open a new editor window, it *still* points to the old (non-existent)
connection, and you get the error shown on this bug if you try to do execute (or do code-completion) with it.

Gads. 

It looks like the ConnectionListener for the combo box model is not getting fired.  Listeners are supposed to be
notified by ConnectionList whenever a connection has changed in some way.  Need to understand why a property change is
not causing the connection listener to be notified.

Build: NetBeans IDE Dev (Build 20080916041613)
VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) SE Runtime Environment, 1.6.0_10-b30
OS: Linux, 2.6.24-19-generic, i386

User Comments: 


Stacktrace: 
java.lang.IllegalStateException: This connection is not added to the ConnectionManager.

Created attachment 69954 [details]
stacktrace

just tried (looks like my comments were striped somewhere):

-start GlassFish
-create new JavaDB connection, ie "xxx"
-connect to it
-invoke Execute command on the newly added connection node
-copy & paste some sql script into the editor (or just type something yourself)
-run it

 => ISE - same stacktrace as in this report

I think this is really basic scenario which simply must work => P1 - I do not consider IDE restart as a user acceptable
workaround for this

*** Issue 144211 has been marked as a duplicate of this issue. ***

The approach I'm leaning toward is to actually create a new connection when the user changes database, user (properties
that would render the current connection invalid), and delete the old one.  This seems like the cleanest approach so
that components that recognize added and deleted connections will respond correctly.

Anyone have any thoughts, objects, etc?

I don't yet understand what exactly causes this issue, but at first sight removing the connection and creating another
one doesn't seem the right approach. This has worked since 2005, what caused it to stop working? I think we should know
that first before deciding how to fix it.

Quoting from desc15:

> What should happen is that in the SQL editor the selected connection should 
> become empty, because the connection that was previously selected no longer exists.

Why? Say I have connection jdbc:mysql://localhost/foo in DB Explorer and also selected in an SQL editor. If the user
modifies the connection URL to jdbc:mysql://localhost/bar, then the "bar" connection should be selected in the SQL
editor. The user is not creating a new connection, just modifying an existing one. If the user is modifying foo to bar,
any place where foo was used should now use bar. Only had the user deleted foo and created bar should the SQL editor
have no selected connection.

Although I'm still digging into the root cause, I'm not sure I agree that changing foo to bar should simply propagate
itself everywhere.  If the SQL editor is using a connection to database XXX and the user changes the connection
properties to now point to database YYY, nothing in the SQL editor from before that change makes sense anymore.

There's also another issue that I don't think has been described. Currently the user has the ability to change the
properties of one connection so that it essentially matches another existing connection.  This needs to be caught
as well.  So there's more than one issue in this one.

First step is to isolate the cause.  I'll post another comment when I have more info.

From what I saw:

steps I mentioned in desc #21
-do work fine for MySQL db
-do not work for Java DB

not sure if that helps/is important...

andrei: do you ever sleep? :)

I agree it would be good to understand why it used to work and why it doesn't.

Perhaps we can go back to say a week before the first detection of this bug in the wild occurred, and see what changed.
 I suspect it's something to do with my mucking around in there trying to get bugs fixed.

That said, I agree with Rob's observations - changing the connection properties fundamentally changes things.  It breaks
the contract with ChildFactory that equals() should be consistent across the life of an instance.  if A.equals(B) it
should always be true that A.equals(B).    We use the database connection name for equals() (and changing this is not an
easy thing - I broke things when I tried to use a UUID, remember?).  So if you change the name (by changing the URL,
user or schema) then you, from the perspective of ChildFactory, have a different beast that requires a new node.

I'm not sure what the right solution is here, but that needs to be taken into account.

One concern I have with removing the old connection and creating a new one is that if there is code using a
DatabaseConnection it's entirely possible this connection will be suddenly removed.  But I guess that can happen already
if someone manually deletes a connection from the explorer.  If you have a ConnectionListener installed you should be
able to detect this and determine if your connection is no longer valid.

> nothing in the SQL editor from before that change makes sense anymore.

Not sure I understand, can you please elaborate?

What if the user simply changes the user name? How about the schema? The user is still connecting to the same database,
so would you clear the SQL editor selection in that case? Also, the user may modify the db URL to point to a similar
database on the same machine, perhaps one with the same database objects -- clearing the selection is unwanted in that
case too.

Let's look at it another way: let's say the user has three connections in the DB Explorer. He has a SQL editor, with
connection #1 selected. The user now modifies connection #1 to point to another database. You suggest that the selection
in the SQL editor connection combo box be cleared. That implies that you suppose the user will want to use one of the
other two connections in the editor -- not the one he has just modified. But that is highly unlikely. If the user
modifies a connection, it is because he still wants to work with it. Not with the other two. So we should keep the
selection in the SQL editor.

> This needs to be caught as well

Agreed, but it is a separate issue.

> and changing this is not an easy thing - I broke things when I tried to use a UUID, remember

I'm not sure why DC overrides equals(). It shouldn't be need to. There shouldn't be a lot of DC instances floating
around  and requiring that you compare them with each other. There should only be as many DC instances as there are
connections in the DB Explorer. Perhaps the problem at that time was that there were too many instances of DC and you
needed to compare them, and of course you need compare them by name. Rob's change to
DatabaseNodeInfo.getDatabaseConnection() would help fix that.

> andrei: do you ever sleep? :)

Nope, I only do guarded waiting :-)

Andrei:

I can't remember all the reasons why the connection name is being used to *identify* the CNI.  Let's just say I had to
give up and back out my change.  Maybe Rob in his most excellence can unravel this bit.  I actually suspect this
dependence on name for identity could very well be at the heart of the current problem.

Regarding what connection to have selected in the editor, I agree that from the user's perspective it would be nice not
to have to re-select the connection.  But I'm willing to sacrifice that if it's the best way to solve this problem in
the time we have.

Don't know either. I can look at the code tomorrow. Or, if you want, I can take this issue.

> But I'm willing to sacrifice that if it's the best way to solve this problem in
> the time we have.

If we can't invent anything better for 6.5, I would be willing too. Good that we agree on what the right behavior is, so
we can fix it properly for 7.0.

Behavior has changed somewhat due to changes to the trunk.  

When changing a connection property, such as the database name, the connection info does get updated.  And if you
subsequently connect, you get a connection.  But if you look at the child nodes, they are wrong.  They are the child
nodes for the previous connection.  They need to be cleared either when the connection is disconnected or when the
properties change.

I don't know if we should consider this a separate issue or just part of this one.

Not sure, but I would consider it separate. Let's keep this issue for tracking the IllegalStateException. I can still
reproduce the ISE when modifying the schema of a Derby connection and then using the connection from the SQL editor.

Agreed.  I'll open a new issue for the child node issue.

Yes, I still see the ISE too.  That part of the behavior hasn't changed ;)

The root of the problem seems to be that when a property of the connection is modified, the connection is not found in
ConnectionList.connectionCache, because the key in connectionCache is the old name.

This at least happens after I modified DatabaseNodeInfo.getDatabaseConnection() to use the existing DC instance instead
of creating a new one.

Yep, that's exactly what I'm looking at.

I'm considering removing the cache. It is really broken. For example, if you try to remove a connection after having
modified its properties, the connection is not removed.

Yes, the cache uses the connection name as its key.  So changing properties means you lose the key.  I'm in the same
code, doing some of the same stuff I think.  I was experimenting with clearing a connection from the cache correctly. 
It seems we're going to step all over each other.  If you're going to get rid of the cache, I'll hold off on this until
you complete that.  I do think it would be a good idea.

Created attachment 70106 [details]
Proposed fix

The attached patch seems to fix the problem. It removes the connection cache, but that doesn't seem to cause any
regressions (I couldn't reproduce either of issue 137811 and issue 142036), since I am also making sure that no
additional DC instances are created. It needs more testing and polishing, but it is a start.

Not sure how to proceed from here. If you like the patch, go ahead and make any modifications you see fit and commit it.
Otherwise I can finish this.

By the way, I do realize I'm stepping on your toes. Sorry for that! Initially I only wanted to find the cause of the
issue, but in order to be sure I needed to make changes to the code, which resulted in the patch, and I didn't want to
throw it away. In a Czech movie there's this joke where a guy gets asked how he became a pathologist. "I used to be a
surgeon, but once while performing a surgery I suddenly realized I was performing an autopsy". I was only evaluating,
but suddely I realized I was fixing :-)

No problem.  I'm glad you found the issue.  Go ahead and finish it.  I managed to uncover a completely different issue
(Issue 147618) in the process of my own forensics :).  So I'll finish that one up.

I'll finish it tomorrow.

#4c829f9abb13

Honza, please verify this issue.

yup, seems to be fine for my scenario now... will check it in some more official build later anyway

Integrated into 'main-golden', will be available in build *200809200201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/4c829f9abb13
User: Andrei Badea <abadea@netbeans.org>
Log: #144819: [test] IllegalStateException: This connection is not added to the ConnectionManager.

v.

*** Issue 145090 has been marked as a duplicate of this issue. ***