Hibernate
/
hibernate-orm
mirror of https://github.com/hibernate/hibernate-orm
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

HHH-6097 - Review log levels, especially related to i18n messages

This commit is contained in:
Steve Ebersole 2011-04-07 12:50:06 -05:00
parent 5408dac36b
commit a616a83d8e
1 changed files with 59 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
documentation/src/main/docbook/devguide/en-US/appendix-Troubleshooting.xml Normal file
View File

@ -0,0 +1,59 @@
<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "Hibernate_Development_Guide.ent">
%BOOK_ENTITIES;
]>
<appendix id="appendix-Troubleshooting">
<title>Troubleshooting</title>
<section>
<title>Log messages</title>
<para>
This section discusses certain log messages you might see from Hibernate and the "meaning" of those
messages. Specifically, it will discuss certain messages having a "message id", which for Hibernate
is always the code <literal>HHH</literal> followed by a numeric code. The table below is ordered
by this code.
</para>
<table>
<title>Explanation of identified log messages</title>
<tgroup cols="2">
<thead>
<row>
<entry>Key</entry>
<entry>Explanation</entry>
</row>
</thead>
<tbody>
<row>
<entry>HHH000002</entry>
<entry>
<para>
Indicates that a session was left associated with the
<classname>org.hibernate.context.ThreadLocalSessionContext</classname> that is used
to implement thread-based current session management. Internally that class uses a
ThreadLocal, and in environments where Threads are pooled this could represent a
potential "bleed through" situation. Consider using a different
<interfacename>org.hibernate.context.CurrentSessionContext</interfacename>
implementation. Otherwise, make sure the sessions always get unbound properly.
</para>
</entry>
</row>
<row>
<entry>HHH000408</entry>
<entry>
<para>
Using workaround for JVM bug in <classname>java.sql.Timestamp</classname>. Certain
JVMs are known to have a bug in the implementation of
<classname>java.sql.Timestamp</classname> that causes the following condition to
evaluate to <literal>false</literal>: <code>new Timestamp(x).getTime() != x</code>.
A huge concern here is to make sure you are not using temporal based optimistic
locking on such JVMs.
</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
</appendix>