Что за ошибка?

[Splinter]

Здравствуйте.
Удалось кому-то решить проблему?

Сейчас началось тоже самое:

20:13:16.696  Multiply prepared statement! DELETE FROM comteleport WHERE charId=
? AND TpId=?;
20:31:59.208  Multiply prepared statement! SELECT COUNT(*) FROM community_skills
ave WHERE charId=? AND id=?;
20:03:30.883  Multiply prepared statement! SELECT COUNT(*) FROM comteleport WHER
E charId=? AND name=?;

WinXP 64bit 32Гб ОЗУ
Выделено под сервер от 6 до 18Гб

Сервер работает стабильно, без лагов, только флуд в GS мягко говоря задрал.

[Splinter]

Вот так это выглядит в логах сервера:

1448215410883	INFO	27	com.mchange.v2.c3p0.stmt.GooGooStatementCache	Multiply prepared statement! SELECT COUNT(*) FROM comteleport WHERE charId=? AND name=?;
1448215410886	INFO	27	com.mchange.v2.c3p0.stmt.GooGooStatementCache	Multiply prepared statement! INSERT INTO comteleport (charId,xPos,yPos,zPos,name) VALUES(?,?,?,?,?)

[Splinter]

Опечатался с операционкой. Win 7 64bit

Проблема актуальна по сей день.
Так как на тот момент написания поста глючил винт и часто контроллер винта захватывал на себя шину, грешил что это может быть из за этого.
Переезд на новый винт и новую систему проблемы не решил.
Расширение тридов в конфиге сервера не помогает.

Какой файл в исходниках посоветуете смотреть?

Сервер основан на исходниках Open-Team, Revolt-Team, СССР времен 2011 года, когда исходники были в шаре. С тех пор это можно сказать стал совсем другой сервер.

[flopix]

Вот что пишут:

The "Multiply prepared statement!" message suggests that perhaps you have multiple Threads sharing at the Connection level. It means that from the same Connection, the same PreparedStatement has been requested twice, which you could conceivably do on purpose in a single thread, but probably means you are unadvisedly sharing the Connection between multiple threads who are using the same code to prepare the same Statement.

http://sourceforge.net/p/c3p0/bugs/7/

Как я понял система вас уведомляет что для одного соединения с БД подготовлено несколько идентичных prepared statement что есть лишней растратой ресурсов.

[Splinter]

Да, это понимаю, что открывается второй поток на то же задание.
Уже пробовал дописать костыль, который не дает быстро сохранять бафы через кнопку сохранения схемы бафов (быстрое прокликивание). Поставил интервал (пример 30 секунд). Чтобы база успевала сохранить предыдущую схему, на случай, если это виновата база и коннект не успевает закрыться, как ему дают новую задачу "Сохранить".

Но номер не удался.

А вот что делать с новыми или старыми версиями c3p0, что по ссылке, не понял, так как не работал с подобным. Сам модуль c3p0, скачанный отдельно, пытался подгрузить с библиотек сервера - естественно вылезла ошибка)

[flopix]

Я в архитектуре баз не силен, но я думаю что эта ошибка чисто на уровне стека c3p0, а не самого сервера MYSql.
Так а сам запрос выполняется или прерывается на этом исключении?

[Splinter]

Все выполняется до логического конца
и все бы ничего, если бы не гадостные сообщения в консоль от таких действий
либо, стоит наоборот задуматься и исправить ошибку, чтобы это не перешло во что-то более глобальное. Ведь её небыло на сервере около 5 лет и вдруг появилась около месяца назад при том же колличестве онлайна

java файлы CommunityBoard не изменял со времен первого запуска сервера, все там нормально было.

[flopix]

У меня на l2open сборке очень редко бывает начинает такое строчить:

Multiply prepared statement! UPDATE items SET owner_id=?,count=?,l
oc=?,loc_data=?,enchant_level=?,shadow_life_time=? ,item_id=?,flags=? WHERE objec
t_id = ? LIMIT 1

И строчит раз в иногда до рестарта. Но никаких косяков это еще не вызвало. Но согласен лучше разобраться.

[Splinter]

Open-Team, скорее всего, исправили эту ошибку(как у меня), судя по их форуму, но помочь отказываются глубоким молчанием.
http://open-team.ru/forum/index.php?...3-rev-777-794/

[Splinter]

Тему можно закрывать, проблему решил.