Read To Rakesh Prajapati

One of the cool feature of Java that I like is ThreadLocal storage. ThreadLocal storage is explained in easiest way with practical example in this blog. ThreadLocal is a class in java.lang package which provides a way to store and access data of any type per thread, which means each thread will have it's separate instance of the data. During execution of a thread, one class can set data in ThreadLocal and other classes further down in the execution layer can access/read the data, as long as execution in within same thread. It is important to know that ThreadLocal data set by one thread is not visible or accessible in another thread. That the core concept of ThreadLocal storage. The way to use ThreadLocal is declare a static property of type ThreadLocal where T is type of the data we want to store. It's static so that it easily accessible in classes wherever needed. You can declare it public, private or whatever make sense in your usecase. Usually declaring it as...

When this goes well, you are happy but every developer hits situation when you need more logs and details to troubleshoot issue and determine root case. It happens many times when you work with JPA and thing don't goes as you expect. You really need to look under the hood what JPA is going, what SQL statements it's generating and executing. Environment: WAS Liberty 17.0.01, JAVA EE 7, JPA 2.1, EclipseLink 2.6.3 In above environment, to enable JPA logging including SQL statements, bind parameters and transaction details do following - Add following tow properties in persistence.xml <property name="eclipselink.logging.level" value="ALL"/> <property name="eclipselink.logging.parameters" value="true"/> Add following logging tag in server.xml <logging traceSpecification="eclipselink=all" maxFileSize="20" maxFiles="10"/> Redeploy application and recycle server. All done! T...