Jeff,

Don't worry, we definitely plan on back-porting this fix to 1.3, it's just that the resources to do so won't be available until after we get 1.4 out of the door. We haven't forgotten you!

C

I'm glad to hear this is finally fixed but I have to say I'm quite disappointed that it doesn't sound like the patch is being made available for previous versions of Confluence. I'll venture a guess that many of your customers (including me) cannot just upgrade their Confluence instance at the drop of a hat, especially when it includes a whole new interface. Many of my users are non-technical and don't appreciate being forced into a new interface without some warning, explanation, and demonstration.

Please consider making the patch available for previous versions of Confluence!

This is great news! Could you share some details on what caused such a weird problem?

Thanks!

Hi Guys,

Good news. We've completed our testing of the patch that will fix this and it will be bundled into 1.4 (due out soon).

Cheers,
Dave

Please do NOT close this issue. Our production environment relies on Oracle databases and we should use it for Confluence datastore as well. The current situation should be considered as a workaround, not a permanent fix!

Please find out if it's Confluence that causes the issue and if it can be worked out. For example, check that there aren't mistakes/misuses in LOB handling: leaving LOBs open for example.

Jarno,

I close this issue now. If you should experience any problems after the migration, please feel free to open the ticket again.

cheers,
Jens

The note about memory leaks in Oracle 10.2.0.2 doesn't really relate to our issue. However, we migrated from Oracle 10g to PostgreSQL 7.4 yesterday. So far everything looks good and we haven't encountered the locking anymore editing, moving or renaming pages.

We're going to migrate the other instance as well, if there are no problems during a couple of days time.

Hi,
Anyone using the Oracle 10g (precise version 10.1.0.2.0) drivers and experiencing performance issues should read the announcement from Oracle below. Among other things it contains notification about a memory leak for large VARCHAR columns - it's a long notice so simply run a search for 'memory leak':

"Some memory Leak when using PreparedStatement with tables
containing large char or varchar column. The problem can be
worked around by enabling statement caching."

There is also notice of problems with the thin client opening connections:

"Programs can fail to open 16 or more connections using our
client-side drivers at any one time. This is not a limitation
caused by the JDBC drivers. It is most likely that the limit of
per-process file descriptors is exceeded. The solution is to
increase the limit."

More at: http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc_readme101020.html

Jamo,
Thanks for the thread dump. Nothing is immediately leaping out at me from it. Four users are viewing a page ... which is code which doesn't leak a connection. It doesn't seem to indicate the cause of the problem.

I think your own idea is quite a good one. I'm curious about whether or not background processes are dropping connections improperly. I'll set something up and let you know.

Cheers,
Nick

Please note that the thread-dump.txt attachment is acquired from separate Confluence instance that is running on OC4J/Oracle Application Server 10g (10.1.2).

I'd appreciate if you double-checked that no background process (mailsender, referralpurge, backups for example) could be able to leave a transaction open if exceptions are thrown.