Re: issues with SQL size st.execute(SQL) in 8.3.3
От | Kris Jurka |
---|---|
Тема | Re: issues with SQL size st.execute(SQL) in 8.3.3 |
Дата | |
Msg-id | Pine.BSO.4.64.0810180941110.26386@leary.csoft.net обсуждение исходный текст |
Ответ на | Re: issues with SQL size st.execute(SQL) in 8.3.3 (Achilleas Mantzios <achill@matrix.gatewaynet.com>) |
Ответы |
Re: issues with SQL size st.execute(SQL) in 8.3.3
|
Список | pgsql-jdbc |
On Sat, 18 Oct 2008, Achilleas Mantzios wrote: > Στις Friday 17 October 2008 20:34:57 ο/η Kris Jurka έγραψε: >> >> It all depends on whether you are relying on any V3 features in other >> places. I have a fix for the issue (attached). I'm still testing it and >> will hopefully apply it this weekend. > > Regarding V2, its just a simple program like the one i showed, > can you point some cases which would explicitly rely on V3 features ? > Which JDBC method calls would be affected by the enforcement of V2? > Can the rest of the backends (other than the one serving the v2 client) be > affected in any way by this? If it's just this connection, then switching to V2 is a fine solution. A simple execute works fine and won't affect anything else. I thought you were considering switching your whole application to V2 which needs a little more thought. As an example ParameterMetaData is only implementable with the V3 protocol. I have applied to previous patch to CVS, and it should fix your problem, but it does not solve every deadlock situation. The deadlock avoidance code was originally written for batch execution which should not be returning ResultSets. If many long queries that return significant results are issued with a single execute we will still deadlock. Solving this would require tracking the bytes actually sent rather than the number of queries sent, or a more significant redesign to use multiple threads or NIO. Attached is sample code which still deadlocks. Kris Jurka
Вложения
В списке pgsql-jdbc по дате отправления: