I am trying to persist data to an embedded Derby DB using hibernate. But data not getting persisted at all.
hibernate configuration
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD//EN"
"http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
<property name="hibernate.connection.url">
jdbc:derby:wso2FlightRecorder
</property>
<property name="hibernate.connection.driver_class">
org.apache.derby.jdbc.EmbeddedDriver
</property>
<property name="hibernate.dialect">
org.hibernate.dialect.DerbyTenSevenDialect
</property>
<property name="connection.username"/>
<property name="connection.password"/>
<!-- DB schema will be updated if needed -->
<property name="hibernate.hbm2ddl.auto">create</property>
<mapping class="org.wso2.esbMonitor.network.PassThruHTTPBean">
</mapping>
</session-factory>
</hibernate-configuration>
This is the DAO class
package org.wso2.esbMonitor.network;
import javax.annotation.Generated;
import javax.persistence.*;
import java.util.Date;
#Entity
#Table(name = "HTTP_LOG")
public class PassThruHTTPBean {
#Id
#GeneratedValue
#Column(name = "id")
private int id;
#Column(name = "activeThreadCount")
private int activeThreadCount;
#Column(name = "avgSizeRecieved")
private double avgSizeRecieved;
#Column(name ="avgSizeSent")
private double avgSizeSent;
#Column(name ="faultsRecieving")
private long faultsRecieving;
#Column(name ="faultSending")
private long faultSending;
#Column(name ="messagesRecieved")
private long messagesRecieved;
#Column(name ="messageSent")
private long messageSent;
#Column(name ="queueSize")
private int queueSize;
#Column(name = "time")
private Date date;
}
This is the method use to commit to DB
public synchronized static void addNetworkTrafficDetailsToDB(){
try {
if (scheduledList.size() > 0){
logger.info("Started persisting");
Session session = HibernateSessionCreator.getSession();
for(PassThruHTTPBean passThruHTTPBean : scheduledList){
Transaction tx;
tx = session.beginTransaction();
session.save(passThruHTTPBean);
tx.commit();
}
session.flush();
session.close();
scheduledList.clear();
}
Stack trace
2016-06-01 09:31:08 DEBUG AbstractTransactionImpl:158 - begin
2016-06-01 09:31:08 DEBUG LogicalConnectionImpl:212 - Obtaining JDBC
connection
2016-06-01 09:31:08 TRACE DriverManagerConnectionProviderImpl:175 - Total
checked-out connections: 0
2016-06-01 09:31:08 TRACE DriverManagerConnectionProviderImpl:181 - Using
pooled JDBC connection, pool size: 0
2016-06-01 09:31:08 DEBUG LogicalConnectionImpl:218 - Obtained JDBC
connection
2016-06-01 09:31:08 DEBUG JdbcTransaction:69 - initial autocommit status: false
2016-06-01 09:31:08 TRACE AbstractServiceRegistryImpl:146 - Initializing service [role=org.hibernate.event.service.spi.EventListenerRegistry]
2016-06-01 09:31:08 TRACE DefaultSaveOrUpdateEventListener:177 - Saving transient instance
2016-06-01 09:31:08 TRACE AbstractSaveEventListener:167 - Saving [org.wso2.esbMonitor.network.PassThruHTTPBean#<null>]
2016-06-01 09:31:08 TRACE ActionQueue:177 - Adding an EntityIdentityInsertAction for [org.wso2.esbMonitor.network.PassThruHTTPBean] object
2016-06-01 09:31:08 TRACE ActionQueue:185 - Executing inserts before finding non-nullable transient entities for early insert: [EntityIdentityInsertAction[org.wso2.esbMonitor.network.PassThruHTTPBean#<null>]]
2016-06-01 09:31:08 TRACE ActionQueue:193 - Adding insert with no non-nullable, transient entities: [EntityIdentityInsertAction[org.wso2.esbMonitor.network.PassThruHTTPBean#<null>]]
2016-06-01 09:31:08 TRACE ActionQueue:211 - Executing insertions before resolved early-insert
2016-06-01 09:31:08 DEBUG ActionQueue:213 - Executing identity-insert immediately
2016-06-01 09:31:08 TRACE AbstractEntityPersister:2960 - Inserting entity: org.wso2.esbMonitor.network.PassThruHTTPBean (native id)
2016-06-01 09:31:08 DEBUG SQL:104 - insert into HTTP_LOG (id, activeThreadCount, avgSizeRecieved, avgSizeSent, time, faultSending, faultsRecieving, messageSent, messagesRecieved, queueSize) values (default, ?, ?, ?, ?, ?, ?, ?, ?, ?)
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:319 - Registering statement [c065801d-0155-0a1f-282f-000004235ae8]
2016-06-01 09:31:08 TRACE AbstractEntityPersister:2780 - Dehydrating entity: [org.wso2.esbMonitor.network.PassThruHTTPBean#<null>]
2016-06-01 09:31:08 TRACE BasicBinder:84 - binding parameter [1] as [INTEGER] - 0
2016-06-01 09:31:08 TRACE BasicBinder:84 - binding parameter [2] as [DOUBLE] - 0.0
2016-06-01 09:31:08 TRACE BasicBinder:84 - binding parameter [3] as [DOUBLE] - 0.0
2016-06-01 09:31:08 TRACE BasicBinder:72 - binding parameter [4] as [TIMESTAMP] - <null>
2016-06-01 09:31:08 TRACE BasicBinder:84 - binding parameter [5] as [BIGINT] - 0
2016-06-01 09:31:08 TRACE BasicBinder:84 - binding parameter [6] as [BIGINT] - 0
2016-06-01 09:31:08 TRACE BasicBinder:84 - binding parameter [7] as [BIGINT] - 0
2016-06-01 09:31:08 TRACE BasicBinder:84 - binding parameter [8] as [BIGINT] - 0
2016-06-01 09:31:08 TRACE BasicBinder:84 - binding parameter [9] as [INTEGER] - 0
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:358 - Releasing statement [c065801d-0155-0a1f-282f-000004235ae8]
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:472 - Closing prepared statement [c065801d-0155-0a1f-282f-000004235ae8]
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:249 - Starting after statement execution processing [ON_CLOSE]
2016-06-01 09:31:08 DEBUG SQL:104 - values identity_val_local()
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:319 - Registering statement [787c0020-0155-0a1f-282f-000004235ae8]
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:374 - Registering result set [org.apache.derby.impl.jdbc.EmbedResultSet42#1718dbaa]
2016-06-01 09:31:08 DEBUG IdentifierGeneratorHelper:93 - Natively generated identity: 1
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:401 - Releasing result set [org.apache.derby.impl.jdbc.EmbedResultSet42#1718dbaa]
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:515 - Closing result set [org.apache.derby.impl.jdbc.EmbedResultSet42#1718dbaa]
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:358 - Releasing statement [787c0020-0155-0a1f-282f-000004235ae8]
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:472 - Closing prepared statement [787c0020-0155-0a1f-282f-000004235ae8]
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:249 - Starting after statement execution processing [ON_CLOSE]
2016-06-01 09:31:08 TRACE UnresolvedEntityInsertActions:214 - No unresolved entity inserts that depended on [[org.wso2.esbMonitor.network.PassThruHTTPBean#1]]
2016-06-01 09:31:08 TRACE UnresolvedEntityInsertActions:121 - No entity insert actions have non-nullable, transient entity dependencies.
2016-06-01 09:31:08 DEBUG AbstractTransactionImpl:173 - committing
2016-06-01 09:31:08 TRACE SessionImpl:403 - Automatically flushing session
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:82 - Flushing session
2016-06-01 09:31:08 DEBUG AbstractFlushingEventListener:144 - Processing flush-time cascades
2016-06-01 09:31:08 DEBUG AbstractFlushingEventListener:185 - Dirty checking collections
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:200 - Flushing entities and processing referenced collections
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:242 - Processing unreferenced collections
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:254 - Scheduling collection removes/(re)creates/updates
2016-06-01 09:31:08 DEBUG AbstractFlushingEventListener:118 - Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects
2016-06-01 09:31:08 DEBUG AbstractFlushingEventListener:125 - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
2016-06-01 09:31:08 DEBUG EntityPrinter:114 - Listing entities:
2016-06-01 09:31:08 DEBUG EntityPrinter:121 - org.wso2.esbMonitor.network.PassThruHTTPBean{date=null, faultsRecieving=0, queueSize=0, activeThreadCount=0, avgSizeRecieved=0.0, messagesRecieved=0, id=1, avgSizeSent=0.0, faultSending=0, messageSent=0}
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:327 - Executing flush
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:249 - Starting after statement execution processing [ON_CLOSE]
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:359 - Post flush
2016-06-01 09:31:08 TRACE SessionImpl:612 - before transaction completion
2016-06-01 09:31:08 DEBUG JdbcTransaction:113 - committed JDBC Connection
2016-06-01 09:31:08 TRACE TransactionCoordinatorImpl:136 - after transaction completion
2016-06-01 09:31:08 TRACE SessionImpl:624 - after transaction completion
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:82 - Flushing session
2016-06-01 09:31:08 DEBUG AbstractFlushingEventListener:144 - Processing flush-time cascades
2016-06-01 09:31:08 DEBUG AbstractFlushingEventListener:185 - Dirty checking collections
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:200 - Flushing entities and processing referenced collections
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:242 - Processing unreferenced collections
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:254 - Scheduling collection removes/(re)creates/updates
2016-06-01 09:31:08 DEBUG AbstractFlushingEventListener:118 - Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects
2016-06-01 09:31:08 DEBUG AbstractFlushingEventListener:125 - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
2016-06-01 09:31:08 DEBUG EntityPrinter:114 - Listing entities:
2016-06-01 09:31:08 DEBUG EntityPrinter:121 - org.wso2.esbMonitor.network.PassThruHTTPBean{date=null, faultsRecieving=0, queueSize=0, activeThreadCount=0, avgSizeRecieved=0.0, messagesRecieved=0, id=1, avgSizeSent=0.0, faultSending=0, messageSent=0}
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:327 - Executing flush
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:249 - Starting after statement execution processing [ON_CLOSE]
2016-06-01 09:31:08 TRACE AbstractFlushingEventListener:359 - Post flush
2016-06-01 09:31:08 TRACE SessionImpl:342 - Closing session
2016-06-01 09:31:08 TRACE JdbcCoordinatorImpl:171 - Closing JDBC container [org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl#4e6454a]
2016-06-01 09:31:08 TRACE LogicalConnectionImpl:164 - Closing logical connection
2016-06-01 09:31:08 DEBUG LogicalConnectionImpl:232 - Releasing JDBC connection
2016-06-01 09:31:08 TRACE DriverManagerConnectionProviderImpl:233 - Returning connection to pool, pool size: 1
2016-06-01 09:31:08 DEBUG LogicalConnectionImpl:250 - Released JDBC connection
2016-06-01 09:31:08 TRACE LogicalConnectionImpl:176 - Logical connection closed
Session factory
public class HibernateSessionCreator {
private static SessionFactory ourSessionFactory;
private static ServiceRegistry serviceRegistry;
public static void init() {
try {
Configuration configuration = new Configuration();
configuration.configure();
serviceRegistry = new ServiceRegistryBuilder().applySettings(configuration.getProperties()).buildServiceRegistry();
ourSessionFactory = new AnnotationConfiguration()
.addAnnotatedClass(PassThruHTTPBean.class)
.configure()
.buildSessionFactory(serviceRegistry);
} catch (Throwable ex) {
throw new ExceptionInInitializerError(ex);
}
}
public static Session getSession() throws HibernateException {
return ourSessionFactory.openSession();
}
Please help me solve the problem :) Thank you in advance
Related
While using Spring's WebClient to retrieve a PDF file from a REST API, I get an error.
Here's the code with the WebClient :
return WebClient.create().get()
.uri(builder.build().toUri())
.accept(MediaType.APPLICATION_PDF)
.exchange()
.flatMap(response -> response.bodyToMono(byte[].class))
.block();
And I'm getting this error from the REST API that serves the file :
03-02-2021 14:32:01.180 [http-nio-8080-exec-6] DEBUG o.s.w.s.m.m.a.HttpEntityMethodProcessor.writeWithMessageConverters - Found 'Content-Type:application/pdf' in response
03-02-2021 14:32:01.181 [http-nio-8080-exec-6] DEBUG o.s.w.s.m.m.a.HttpEntityMethodProcessor.traceDebug - Writing [InputStream resource [resource loaded through InputStream]]
03-02-2021 14:32:01.185 [http-nio-8080-exec-6] DEBUG o.s.o.j.s.OpenEntityManagerInViewInterceptor.afterCompletion - Closing JPA EntityManager in OpenEntityManagerInViewInterceptor
03-02-2021 14:32:01.186 [http-nio-8080-exec-6] DEBUG o.s.web.servlet.DispatcherServlet.logResult - Completed 200 OK
03-02-2021 14:32:01.187 [http-nio-8080-exec-6] DEBUG o.a.t.util.net.SocketWrapperBase.log - Socket: [org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper#d1d3000:org.apache.tomcat.util.net.NioChannel#4b5f2cea:java.nio.channels.SocketChannel[connected local=/127.0.0.1:8080 remote=/127.0.0.1:57797]], Read from buffer: [0]
03-02-2021 14:32:01.187 [http-nio-8080-exec-6] DEBUG o.a.coyote.http11.Http11Processor.log - Error parsing HTTP request header
java.io.EOFException: null
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1230)
at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.read(NioEndpoint.java:1140)
at org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:780)
at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:356)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1589)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:834)
03-02-2021 14:32:01.188 [http-nio-8080-exec-6] DEBUG o.a.coyote.http11.Http11Processor.log - Socket: [org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper#d1d3000:org.apache.tomcat.util.net.NioChannel#4b5f2cea:java.nio.channels.SocketChannel[connected local=/127.0.0.1:8080 remote=/127.0.0.1:57797]], Status in: [OPEN_READ], State out: [CLOSED]
03-02-2021 14:32:01.188 [http-nio-8080-exec-6] DEBUG o.a.coyote.http11.Http11NioProtocol.log - Pushed Processor [org.apache.coyote.http11.Http11Processor#1c06182a]
03-02-2021 14:32:01.188 [http-nio-8080-exec-6] DEBUG o.a.tomcat.util.threads.LimitLatch.log - Counting down[http-nio-8080-exec-6] latch=2
03-02-2021 14:32:01.188 [http-nio-8080-exec-6] DEBUG o.apache.tomcat.util.net.NioEndpoint.log - Calling [org.apache.tomcat.util.net.NioEndpoint#6df434e4].closeSocket([org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper#d1d3000:org.apache.tomcat.util.net.NioChannel#4b5f2cea:java.nio.channels.SocketChannel[connected local=/127.0.0.1:8080 remote=/127.0.0.1:57797]])
03-02-2021 14:32:08.051 [HikariPool-1 housekeeper] DEBUG com.zaxxer.hikari.pool.HikariPool.logPoolState - HikariPool-1 - Pool stats (total=10, active=0, idle=10, waiting=0)
03-02-2021 14:32:08.051 [HikariPool-1 housekeeper] DEBUG com.zaxxer.hikari.pool.HikariPool.fillPool - HikariPool-1 - Fill pool skipped, pool is at sufficient level.
03-02-2021 14:32:31.180 [Catalina-utility-2] DEBUG o.a.catalina.session.ManagerBase.log - Start expire sessions StandardManager at 1612359151180 sessioncount 0
03-02-2021 14:32:31.180 [Catalina-utility-2] DEBUG o.a.catalina.session.ManagerBase.log - End expire sessions StandardManager processingTime 0 expired sessions: 0
03-02-2021 14:32:34.196 [http-nio-8080-exec-1] DEBUG o.a.coyote.http11.Http11NioProtocol.log - Processing socket [org.apache.tomcat.util.net.NioChannel#6a7679d5:java.nio.channels.SocketChannel[connected local=/0:0:0:0:0:0:0:1:8080 remote=/0:0:0:0:0:0:0:1:57771]] with status [ERROR]
03-02-2021 14:32:34.196 [http-nio-8080-exec-1] DEBUG o.a.coyote.http11.Http11NioProtocol.log - Found processor [null] for socket [org.apache.tomcat.util.net.NioChannel#6a7679d5:java.nio.channels.SocketChannel[connected local=/0:0:0:0:0:0:0:1:8080 remote=/0:0:0:0:0:0:0:1:57771]]
03-02-2021 14:32:34.196 [http-nio-8080-exec-1] DEBUG o.a.tomcat.util.threads.LimitLatch.log - Counting down[http-nio-8080-exec-1] latch=1
03-02-2021 14:32:34.196 [http-nio-8080-exec-1] DEBUG o.apache.tomcat.util.net.NioEndpoint.log - Calling [org.apache.tomcat.util.net.NioEndpoint#6df434e4].closeSocket([org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper#1bf3167e:org.apache.tomcat.util.net.NioChannel#6a7679d5:java.nio.channels.SocketChannel[connected local=/0:0:0:0:0:0:0:1:8080 remote=/0:0:0:0:0:0:0:1:57771]])
Any idea where the problem is ?
Thanx
VERSION
Red Hat Build of Quarkus
<properties>
<compiler-plugin.version>3.8.1</compiler-plugin.version>
<maven.compiler.parameters>true</maven.compiler.parameters>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<quarkus-plugin.version>1.7.5.Final</quarkus-plugin.version>
<quarkus.platform.artifact-id>quarkus-universe-bom</quarkus.platform.artifact-id>
<quarkus.platform.group-id>io.quarkus</quarkus.platform.group-id>
<quarkus.platform.version>1.7.5.Final</quarkus.platform.version>
<surefire-plugin.version>3.0.0-M5</surefire-plugin.version>
</properties>
I am totally confused about this inconsistency and despite logging set to the maximum, all I see is that my code is not behaving the same in this project as compared to other projects.
Everything is configured the same for versions and settings.
I have three quarkus jax-rs services with hibernate-orm pushing to PostgreSQL.
2 of the services all behave as expected with approximately 25 identically configured PUT endpoints with a merge backing manager (code below). In the two working services, the statement in the logs shows where an UPDATE statement is required. However, the third (new) service simply ignores the change. It responds with 200 and even returns the updated data, but the database is never updated.
simple entity
#Entity
#Table(name = "applicants")
public class Applicant implements Serializable {
private static final long serialVersionUID = 6796452320678418766L;
#Column(name = "applicant_id")
#Id
#GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "applicant_seq")
public long applicant_id;
#Column(name = "email", nullable = false, unique = true)
public String email;
}
#PUT Resource
#PUT
#Path("{id}")
public Response update(#PathParam("id") Long id, #Valid Applicant applicant) {
try {
Applicant applicantToUpdate = this.manager.findById(id);
if (applicantToUpdate != null) {
applicantToUpdate = this.manager.save(applicant);
if (applicantToUpdate != null) {
return Response.ok(applicantToUpdate).build();
} else {
...
}
}
return Response.status(Response.Status.NOT_FOUND).build();
} catch (Exception ex) {
...
}
}
Backing Manager for persistance
#Transactional
public Applicant save(Applicant applicant) {
return this.em.merge(applicant);
}
Both the ApplicantResource and the ApplicantManager classes are #RequestScoped.
The logs for the failing service
2020-11-16 13:51:26,122 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) `hibernate.connection.provider_disables_autocommit` was enabled. This setting should only be enabled when you are certain that the Connections given to Hibernate by the ConnectionProvider have auto-commit disabled. Enabling this setting when the Connections do not have auto-commit disabled will lead to Hibernate executing SQL operations outside of any JDBC/SQL transaction.
2020-11-16 13:51:26,123 DEBUG [org.hib.SQL] (executor-thread-198)
select
applicant0_.applicant_id as applican1_0_0_,
applicant0_.email as email2_0_0_
from
applicants applicant0_
where
applicant0_.applicant_id=?
Hibernate:
select
applicant0_.applicant_id as applican1_0_0_,
applicant0_.email as email2_0_0_
from
applicants applicant0_
where
applicant0_.applicant_id=?
2020-11-16 13:51:26,156 DEBUG [org.hib.loa.pla.exe.pro.int.EntityReferenceInitializerImpl] (executor-thread-198) On call to EntityIdentifierReaderImpl#resolve, EntityKey was already known; should only happen on root returns with an optional identifier specified
2020-11-16 13:51:26,156 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Resolving attributes for [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,157 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Processing attribute `email` : value = original#email.com
2020-11-16 13:51:26,157 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Attribute (`email`) - enhanced for lazy-loading? - false
2020-11-16 13:51:26,157 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Done materializing entity [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,159 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterStatement
2020-11-16 13:51:26,159 DEBUG [org.hib.loa.ent.pla.AbstractLoadPlanBasedEntityLoader] (executor-thread-198) Done entity load : org.protechskillsinstitute.applicant.entity.Applicant#1
2020-11-16 13:51:26,159 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterTransaction
2020-11-16 13:51:26,160 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) `hibernate.connection.provider_disables_autocommit` was enabled. This setting should only be enabled when you are certain that the Connections given to Hibernate by the ConnectionProvider have auto-commit disabled. Enabling this setting when the Connections do not have auto-commit disabled will lead to Hibernate executing SQL operations outside of any JDBC/SQL transaction.
2020-11-16 13:51:26,160 DEBUG [org.hib.res.tra.bac.jta.int.JtaTransactionCoordinatorImpl] (executor-thread-198) Hibernate RegisteredSynchronization successfully registered with JTA platform
2020-11-16 13:51:26,161 DEBUG [org.hib.res.tra.bac.jta.int.JtaTransactionCoordinatorImpl] (executor-thread-198) JTA transaction was already joined (RegisteredSynchronization already registered)
2020-11-16 13:51:26,161 DEBUG [org.hib.eve.int.EntityCopyObserverFactoryInitiator] (executor-thread-198) Configured EntityCopyObserver strategy: disallow
2020-11-16 13:51:26,161 DEBUG [org.hib.loa.Loader] (executor-thread-198) Loading entity: [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,212 DEBUG [org.hib.SQL] (executor-thread-198)
select
applicant0_.applicant_id as applican1_0_0_,
applicant0_.email as email2_0_0_
from
applicants applicant0_
where
applicant0_.applicant_id=?
Hibernate:
select
applicant0_.applicant_id as applican1_0_0_,
applicant0_.email as email2_0_0_
from
applicants applicant0_
where
applicant0_.applicant_id=?
2020-11-16 13:51:26,216 DEBUG [org.hib.loa.Loader] (executor-thread-198) Result set row: 0
2020-11-16 13:51:26,216 DEBUG [org.hib.loa.Loader] (executor-thread-198) Result row: EntityKey[org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,217 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Resolving attributes for [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,217 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Processing attribute `email` : value = original#email.com
2020-11-16 13:51:26,217 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Attribute (`email`) - enhanced for lazy-loading? - false
2020-11-16 13:51:26,217 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Done materializing entity [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,218 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterStatement
2020-11-16 13:51:26,218 DEBUG [org.hib.loa.Loader] (executor-thread-198) Done entity load
2020-11-16 13:51:26,219 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Processing flush-time cascades
2020-11-16 13:51:26,219 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Dirty checking collections
2020-11-16 13:51:26,219 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects
2020-11-16 13:51:26,220 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
2020-11-16 13:51:26,220 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) Listing entities:
2020-11-16 13:51:26,220 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) org.protechskillsinstitute.applicant.entity.Applicant{applicant_id=1, email=stephen.w.boyd#gmail.com}
2020-11-16 13:51:26,220 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterStatement
2020-11-16 13:51:26,221 DEBUG [org.hib.eng.tra.int.TransactionImpl] (executor-thread-198) On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Processing flush-time cascades
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Dirty checking collections
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects
2020-11-16 13:51:26,222 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
2020-11-16 13:51:26,222 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) Listing entities:
2020-11-16 13:51:26,222 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) org.protechskillsinstitute.applicant.entity.Applicant{applicant_id=1, email=edited#email.com}
2020-11-16 13:51:26,222 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterStatement
2020-11-16 13:51:26,223 INFO [org.hib.eng.int.StatisticalLoggingSessionEventListener] (executor-thread-198) Session Metrics {
112700 nanoseconds spent acquiring 1 JDBC connections;
9700 nanoseconds spent releasing 1 JDBC connections;
147400 nanoseconds spent preparing 1 JDBC statements;
340500 nanoseconds spent executing 1 JDBC statements;
0 nanoseconds spent executing 0 JDBC batches;
0 nanoseconds spent performing 0 L2C puts;
0 nanoseconds spent performing 0 L2C hits;
0 nanoseconds spent performing 0 L2C misses;
3546700 nanoseconds spent executing 2 flushes (flushing a total of 2 entities and 0 collections);
0 nanoseconds spent executing 0 partial-flushes (flushing a total of 0 entities and 0 collections)
}
2020-11-16 13:51:26,227 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterTransaction
2020-11-16 13:51:26,230 INFO [org.hib.eng.int.StatisticalLoggingSessionEventListener] (executor-thread-198) Session Metrics {
34900 nanoseconds spent acquiring 1 JDBC connections;
18700 nanoseconds spent releasing 1 JDBC connections;
77500 nanoseconds spent preparing 1 JDBC statements;
430200 nanoseconds spent executing 1 JDBC statements;
0 nanoseconds spent executing 0 JDBC batches;
0 nanoseconds spent performing 0 L2C puts;
0 nanoseconds spent performing 0 L2C hits;
0 nanoseconds spent performing 0 L2C misses;
0 nanoseconds spent executing 0 flushes (flushing a total of 0 entities and 0 collections);
0 nanoseconds spent executing 0 partial-flushes (flushing a total of 0 entities and 0 collections)
}
Everything in the code and logs are identical for the working and non-working services with one exception. The log shows the Update is required for the working services and does not for the failing service.
Thoughts? As always, thank you for your assistance!
Drilled in logs
2020-11-16 13:51:26,156 DEBUG [org.hib.loa.pla.exe.pro.int.EntityReferenceInitializerImpl] (executor-thread-198) On call to EntityIdentifierReaderImpl#resolve, EntityKey was already known; should only happen on root returns with an optional identifier specified
2020-11-16 13:51:26,156 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Resolving attributes for [org.protechskillsinstitute.applicant.entity.Applicant#1]
2020-11-16 13:51:26,157 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Processing attribute `email` : value = original#email.com
2020-11-16 13:51:26,157 DEBUG [org.hib.eng.int.TwoPhaseLoad] (executor-thread-198) Attribute (`email`) - enhanced for lazy-loading? - false
and the check
11-16 13:51:26,220 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) Listing entities:
2020-11-16 13:51:26,220 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) org.protechskillsinstitute.applicant.entity.Applicant{applicant_id=1, email=edited#email.com}
2020-11-16 13:51:26,220 DEBUG [org.hib.res.jdb.int.LogicalConnectionManagedImpl] (executor-thread-198) Initiating JDBC connection release from afterStatement
2020-11-16 13:51:26,221 DEBUG [org.hib.eng.tra.int.TransactionImpl] (executor-thread-198) On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Processing flush-time cascades
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Dirty checking collections
2020-11-16 13:51:26,221 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects
2020-11-16 13:51:26,222 DEBUG [org.hib.eve.int.AbstractFlushingEventListener] (executor-thread-198) Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
2020-11-16 13:51:26,222 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) Listing entities:
2020-11-16 13:51:26,222 DEBUG [org.hib.int.uti.EntityPrinter] (executor-thread-198) org.protechskillsinstitute.applicant.entity.Applicant{applicant_id=1, email=edited#email.com}
Are you sure the email actually changed? Hibernate will obviously not execute an update query if the data didn't change.
Have you tried flush and commit after merge? did you check if the flush mode is manual or auto?
Based on the Resolved Dependencies it looks like Red Hat is using:
hibernate-core: 5.4.21.Final-redhat-00001
hibarenate-commons-annotations: 5.1.0.Final-redhat-00005
hibernate-graalvm: 5.4.21.Final-redhat-00001
Per the comments below, I have opened a ticket with Red Hat.
Case 02805123
I am using Hibernate 4.13 and Spring 4
If I try to store timestamp values on Oracle, it fails. But surprisingly, it works on OracleXE. Only difference in schema is, On Oracle I have partition on that table. On OracleXE, I dont.
On Oracle,
While printing entity it shows value correctly.
2018-03-19 11:25:59.456 DEBUG
[org.hibernate.internal.util.EntityPrinter : qtp771935287-17] -
net.jigarshah.domain.MyEntity{myId=123123,
myUuid=ef5c5159-1e91-4a8e-a3bb-8f583fb3cce2,
receivedOn=2018-03-19T11:25:59.277+01:00[Arctic/Longyearbyen], errorCode=null,
lastUpdatedOn=2018-03-19T11:25:59.274+01:00[Arctic/Longyearbyen], id=42001, status=RECEIVED}
In Insert it just removed those values
2018-03-19 11:25:59.470 TRACE [org.hibernate.type.descriptor.sql.BasicBinder : qtp771935287-17] -
binding parameter [3] as [TIMESTAMP] - [null]
2018-03-19 11:25:59.470 TRACE [org.hibernate.type.descriptor.sql.BasicBinder : qtp771935287-17] -
binding parameter [4] as [TIMESTAMP] - [null]
Complete logs
2018-03-19 11:25:59.278 DEBUG [org.springframework.transaction.support.AbstractPlatformTransactionManager : qtp771935287-17] - Initiating transaction commit
2018-03-19 11:25:59.278 DEBUG [org.springframework.orm.hibernate4.HibernateTransactionManager : qtp771935287-17] - Committing Hibernate transaction on Session [SessionImpl(PersistenceContext[entityKeys=[EntityKey[net.jigarshah.domain.MyEntity#42001]],collectionKeys=[]];ActionQueue[insertions=org.hibernate.engine.spi.ExecutableList#425f14f6 updates=org.hibernate.engine.spi.ExecutableList#390223c9 deletions=org.hibernate.engine.spi.ExecutableList#611117d9 orphanRemovals=org.hibernate.engine.spi.ExecutableList#1bb9208a collectionCreations=org.hibernate.engine.spi.ExecutableList#21fb6faf collectionRemovals=org.hibernate.engine.spi.ExecutableList#94f1c32 collectionUpdates=org.hibernate.engine.spi.ExecutableList#60897d1d collectionQueuedOps=org.hibernate.engine.spi.ExecutableList#3266acf6 unresolvedInsertDependencies=UnresolvedEntityInsertActions[]])]
2018-03-19 11:25:59.278 DEBUG [org.hibernate.engine.transaction.spi.AbstractTransactionImpl : qtp771935287-17] - committing
2018-03-19 11:25:59.278 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener : qtp771935287-17] - Processing flush-time cascades
2018-03-19 11:25:59.278 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener : qtp771935287-17] - Dirty checking collections
2018-03-19 11:25:59.455 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener : qtp771935287-17] - Flushed: 1 insertions, 1 updates, 0 deletions to 1 objects
2018-03-19 11:25:59.455 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener : qtp771935287-17] - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
2018-03-19 11:25:59.455 DEBUG [org.hibernate.internal.util.EntityPrinter : qtp771935287-17] - Listing entities:
2018-03-19 11:25:59.456 DEBUG [org.hibernate.internal.util.EntityPrinter : qtp771935287-17] - net.jigarshah.domain.MyEntity{myId=123123, myUuid=ef5c5159-1e91-4a8e-a3bb-8f583fb3cce2, receivedOn=2018-03-19T11:25:59.277+01:00[Arctic/Longyearbyen], errorCode=null, lastUpdatedOn=2018-03-19T11:25:59.274+01:00[Arctic/Longyearbyen], id=42001, status=RECEIVED}
2018-03-19 11:25:59.468 DEBUG [org.hibernate.engine.jdbc.spi.SqlStatementLogger : qtp771935287-17] -
insert
into
my_entity
(my_id, error_code, last_updated_on, received_on, my_uuid, status, id)
values
(?, ?, ?, ?, ?, ?, ?)
2018-03-19 11:25:59.469 TRACE [org.hibernate.type.descriptor.sql.BasicBinder : qtp771935287-17] - binding parameter [1] as [VARCHAR] - [123123]
2018-03-19 11:25:59.469 TRACE [org.hibernate.type.descriptor.sql.BasicBinder : qtp771935287-17] - binding parameter [2] as [VARCHAR] - [null]
2018-03-19 11:25:59.470 TRACE [org.hibernate.type.descriptor.sql.BasicBinder : qtp771935287-17] - binding parameter [3] as [TIMESTAMP] - [null]
2018-03-19 11:25:59.470 TRACE [org.hibernate.type.descriptor.sql.BasicBinder : qtp771935287-17] - binding parameter [4] as [TIMESTAMP] - [null]
2018-03-19 11:25:59.470 TRACE [org.hibernate.type.descriptor.sql.BasicBinder : qtp771935287-17] - binding parameter [5] as [BINARY] - [ef5c5159-1e91-4a8e-a3bb-8f583fb3cce2]
2018-03-19 11:25:59.471 TRACE [org.hibernate.type.EnumType$EnumValueMapperSupport : qtp771935287-17] - Binding [RECEIVED] to parameter: [6]
2018-03-19 11:25:59.472 TRACE [org.hibernate.type.descriptor.sql.BasicBinder : qtp771935287-17] - binding parameter [7] as [BIGINT] - [42001]
2018-03-19 11:25:59.472 DEBUG [org.hibernate.engine.jdbc.batch.internal.BatchingBatch : qtp771935287-17] - Executing batch size: 1
Type conversion
LocalSessionFactoryBuilder builder = new LocalSessionFactoryBuilder(dataSource());
builder.setNamingStrategy(ImprovedNamingStrategy.INSTANCE);
builder.scanPackages(packages);
builder.addProperties(createHibernateProperties());
new **StandardTypeOverrideApplier**(builder).apply();
SessionFactory sessionFactory = builder.buildSessionFactory();
return sessionFactory;
Type converter
private Configuration configuration;
public StandardTypeOverrideApplier(Configuration configuration) {
this.configuration = configuration;
}
public void apply() {
configuration.registerTypeOverride(jvm(new org.jadira.usertype.dateandtime.joda.PersistentDateTime()), new String[]{"jodaDateTime", DateTime.class.getName()});
configuration.registerTypeOverride(new org.jadira.usertype.dateandtime.joda.PersistentLocalDate(), new String[]{"jodaLocalDate", org.joda.time.LocalDate.class.getName()});
**configuration.registerTypeOverride(new PersistentZonedDateTime(), new String[]{"zonedDateTime", ZonedDateTime.class.getName()});**
configuration.registerTypeOverride(new PersistentLocalDate(), new String[]{"localDate", LocalDate.class.getName()});
}
This had nothing to do with Type conversion. Issue was with SavOrUpdateEvent Listner.
I was updating receivedOn value in saveOrUpdate event Listner. Unfortunately, hibernate first creates insert query which does not have timestamp. and Then update query to update receivedOn. And since I had index on receivedOn, if never created update query. It was always failing on insert itself. I would really appriciate if anyone knows alter native to #PreCreate and #PreUpdate in case of hibernate saveOrUpdate. (unfortunately we cant get rid of saveOrUpdate due to some historical reasons in code base)
need your help, I have log4j.properties like this
# Root logger option
log4j.rootLogger=stdout, file
# Redirect log messages to console
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
# Redirect log messages to a log file
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.File=${catalina.home}/logs/Admin.log
log4j.appender.file.MaxFileSize=5MB
log4j.appender.file.MaxBackupIndex=10
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
and this is my Controller
#SuppressWarnings("unused")
#RequestMapping(value="/addedc", method = RequestMethod.POST, consumes = "application/json", headers = "content-type=application/x-www-form-urlencoded")
public #ResponseBody Status_new addedc(#RequestBody installasimodel edc){
log.info("<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< START ADDEDC >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>");
log.debug("qqqqqqqqqqqqqq");
List<installasimodel>mapusr = null;
try{
insta.addistlsi(edc);
log.info(new Status_new(1, "Sukses!"));
return new Status_new(1, "Sukses!");
}catch(Exception mapi){
log.info(new Status_new(0, mapi.getMessage()));
log.info("<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< STOP ADDEDC >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>");
return new Status_new(0, mapi.getMessage());
}
}
I want to show "INFO" in the file .log, but why DEBUG also appear? thus fulfilling the page.This example logs generated
....
....
2016-02-05 15:14:58 DEBUG FilterSecurityInterceptor:185 - Public object - authentication not attempted
2016-02-05 15:14:58 DEBUG FilterChainProxy:323 - /ins-server-insta/ins-list-all-insta-installasi reached end of additional filter chain; proceeding with original chain
2016-02-05 15:14:58 DEBUG DispatcherServlet:838 - DispatcherServlet with name 'mvc-dispatcher' processing GET request for [/admin-teknikal/ins-server-insta/ins-list-all-insta-installasi]
2016-02-05 15:14:58 DEBUG RequestMappingHandlerMapping:246 - Looking up handler method for path /ins-server-insta/ins-list-all-insta-installasi
2016-02-05 15:14:58 DEBUG RequestMappingHandlerMapping:251 - Returning handler method [public java.util.List<com.bni.edc.model.installasimodel> com.bni.edc.controller.instaController.getInsta()]
2016-02-05 15:14:58 DEBUG DefaultListableBeanFactory:249 - Returning cached instance of singleton bean 'instaController'
2016-02-05 15:14:58 DEBUG DispatcherServlet:925 - Last-Modified value for [/admin-teknikal/ins-server-insta/ins-list-all-insta-installasi] is: -1
2016-02-05 15:14:58 INFO nanda:63 - <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< START ALL INSTALLASI LIST >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2016-02-05 15:14:58 DEBUG AbstractTransactionImpl:160 - begin
2016-02-05 15:14:58 DEBUG LogicalConnectionImpl:226 - Obtaining JDBC connection
2016-02-05 15:14:58 DEBUG DriverManagerDataSource:142 - Creating new JDBC DriverManager Connection to [jdbc:mysql://localhost:3306/bni]
2016-02-05 15:14:58 DEBUG LogicalConnectionImpl:232 - Obtained JDBC connection
2016-02-05 15:14:58 DEBUG JdbcTransaction:69 - initial autocommit status: true
2016-02-05 15:14:58 DEBUG JdbcTransaction:71 - disabling autocommit
2016-02-05 15:14:58 DEBUG SQL:109 - SELECT * FROM istlsi_edc_tkn_tebel WHERE sts!='1' ORDER BY id_istlsi_tkn DESC
2016-02-05 15:14:58 DEBUG Loader:951 - Result set row: 0
2016-02-05 15:14:58 DEBUG Loader:1485 - Result row: EntityKey[com.bni.edc.model.installasimodel#22344444]
2016-02-05 15:14:58 DEBUG Loader:951 - Result set row: 1
2016-02-05 15:14:58 DEBUG Loader:1485 - Result row: EntityKey[com.bni.edc.model.installasimodel#232323]
2016-02-05 15:14:58 DEBUG TwoPhaseLoad:160 - Resolving associations for [com.bni.edc.model.installasimodel#22344444]
2016-02-05 15:14:58 DEBUG TwoPhaseLoad:286 - Done materializing entity [com.bni.edc.model.installasimodel#22344444]
2016-02-05 15:14:58 DEBUG TwoPhaseLoad:160 - Resolving associations for [com.bni.edc.model.installasimodel#232323]
2016-02-05 15:14:58 DEBUG TwoPhaseLoad:286 - Done materializing entity [com.bni.edc.model.installasimodel#232323]
2016-02-05 15:14:58 DEBUG AbstractTransactionImpl:175 - committing
2016-02-05 15:14:58 DEBUG AbstractFlushingEventListener:149 - Processing flush-time cascades
2016-02-05 15:14:58 DEBUG AbstractFlushingEventListener:189 - Dirty checking collections
2016-02-05 15:14:58 DEBUG AbstractFlushingEventListener:123 - Flushed: 0 insertions, 0 updates, 0 deletions to 2 objects
2016-02-05 15:14:58 DEBUG AbstractFlushingEventListener:130 - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
2016-02-05 15:14:58 DEBUG EntityPrinter:114 - Listing entities:
2016-02-05 15:14:58 DEBUG EntityPrinter:121 - com.bni.edc.model.installasimodel{tngl_qrcode=null, tngl_sbm_istlsi=null, tngl_sbmit=2016-02-04, ttd_mrchn=null, kde_pos_sls=0, own=BN, mid=23232323, hp_penerima=null, id_istlsi_tkn=48, id_wlyh=1, tid=232323, id_spv=0, foto_istlsi=null, sc=1, ttd_istlsi=null, alamat_mrchn=asasa, jam=null, kde_pos=0, sn=null, ket_istlsi=sdsddsdsdsdsd, kde_pos_tkn=null, ntf_adm=0, ttd=null, ms=null, id_tkn=28, koor_lat=null, gprs_id=null, tngl_chck_adm=null, version=null, koor_long=null, sts=0, foto=null, phone=23232, nm_penerima=daa, sts_edc=0, id_usr_adm_sls=0, own_mrchn=null, nm_mrchn=dsds, id_usr_sls=0}
2016-02-05 15:14:58 DEBUG EntityPrinter:121 - com.bni.edc.model.installasimodel{tngl_qrcode=null, tngl_sbm_istlsi=null, tngl_sbmit=2016-02-04, ttd_mrchn=null, kde_pos_sls=0, own=BN, mid=20397878789, hp_penerima=null, id_istlsi_tkn=49, id_wlyh=3, tid=22344444, id_spv=0, foto_istlsi=null, sc=1, ttd_istlsi=null, alamat_mrchn=jl.soedirman kav.04, jam=null, kde_pos=0, sn=null, ket_istlsi=butuh cepat dan segera, kde_pos_tkn=null, ntf_adm=0, ttd=null, ms=null, id_tkn=27, koor_lat=null, gprs_id=null, tngl_chck_adm=null, version=null, koor_long=null, sts=0, foto=null, phone=09787879, nm_penerima=yuyun, sts_edc=0, id_usr_adm_sls=0, own_mrchn=null, nm_mrchn=laksana baru, id_usr_sls=0}
2016-02-05 15:14:58 DEBUG JdbcTransaction:113 - committed JDBC Connection
2016-02-05 15:14:58 DEBUG JdbcTransaction:126 - re-enabling autocommit
2016-02-05 15:14:58 DEBUG LogicalConnectionImpl:246 - Releasing JDBC connection
2016-02-05 15:14:58 DEBUG LogicalConnectionImpl:264 - Released JDBC connection
2016-02-05 15:14:58 INFO nanda:71 - <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< STOP ALL INSTALLASI LIST >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
....
how can I disable DEBUG ?
Change DEBUG to INFO
log4j.rootLogger=DEBUG, stdout, file
I'm assuming that you are using Log4j v1.x...
In your configuration properties you're only configuring appenders (root logger output will be sent to stdout end file):
log4j.rootLogger=stdout, file
but you aren't specifying logging level (default level is DEBUG), so everything is logged on your appenders.
To set a specific logging level you need to configure it properly. In particular, if you need to log only from INFO level to FATAL level, you have to set this:
log4j.rootLogger=INFO, stdout, file
Take a look: https://logging.apache.org/log4j/1.2/manual.html
UPDATE
If you need to log Hibernate activities (only INFO level) you also need to set these configurations:
log4j.logger.org.hibernate=INFO, stdout, file
You are not setting the Logging Level in your log4j.xml.
Set your Logger level to INFO like this:
# Root logger option
log4j.rootLogger=INFO, stdout, file
Change this log4j.rootLogger=stdout, file to log4j.rootLogger= INFO, stdout, file
Solution A: Initialize root logger with level INFO for stdout and file
log4j.rootLogger=INFO,stdout,file
Solution B: Set the log level for specified components
log4j.logger.com.endeca=INFO
This program does tens of thousands of consecutive inserts one after the other. I've never used Hibernate before. I'm getting extremely slow performance (if I just connect and execute the SQL manually I am 10-12x quicker. My batch_size is set to 50 as per many hibernate tutorials.
Here is a log from a single insert - perhaps you could help me understand exactly what is happening:
START INSERT
11:02:56.121 [main] DEBUG org.hibernate.impl.SessionImpl - opened session at timestamp: 13106053761
11:02:56.121 [main] DEBUG o.h.transaction.JDBCTransaction - begin
11:02:56.121 [main] DEBUG org.hibernate.jdbc.ConnectionManager - opening JDBC connection
11:02:56.121 [main] TRACE o.h.c.DriverManagerConnectionProvider - total checked-out connections: 0
11:02:56.121 [main] TRACE o.h.c.DriverManagerConnectionProvider - using pooled JDBC connection, pool size: 0
11:02:56.121 [main] DEBUG o.h.transaction.JDBCTransaction - current autocommit status: false
11:02:56.121 [main] TRACE org.hibernate.jdbc.JDBCContext - after transaction begin
11:02:56.121 [main] TRACE org.hibernate.impl.SessionImpl - setting flush mode to: MANUAL
11:02:56.121 [main] TRACE o.h.e.def.DefaultLoadEventListener - loading entity: [com.xyzcompany.foo.edoi.ejb.msw000.MSW000Rec#component[keyW000]{keyW000=F000 ADSUFC}]
11:02:56.121 [main] TRACE o.h.e.def.DefaultLoadEventListener - creating new proxy for entity
11:02:56.122 [main] TRACE o.h.e.d.DefaultSaveOrUpdateEventListener - saving transient instance
11:02:56.122 [main] DEBUG o.h.e.def.AbstractSaveEventListener - generated identifier: component[keyW000]{keyW000=F000 ADSUFC}, using strategy: org.hibernate.id.CompositeNestedGeneratedValueGenerator
11:02:56.122 [main] TRACE o.h.e.def.AbstractSaveEventListener - saving [com.xyzcompany.foo.edoi.ejb.msw000.MSW000Rec#component[keyW000]{keyW000=F000 ADSUFC}]
11:02:56.123 [main] TRACE o.h.e.d.AbstractFlushingEventListener - flushing session
11:02:56.123 [main] DEBUG o.h.e.d.AbstractFlushingEventListener - processing flush-time cascades
11:02:56.123 [main] DEBUG o.h.e.d.AbstractFlushingEventListener - dirty checking collections
11:02:56.123 [main] TRACE o.h.e.d.AbstractFlushingEventListener - Flushing entities and processing referenced collections
11:02:56.125 [main] TRACE o.h.e.d.AbstractFlushingEventListener - Processing unreferenced collections
11:02:56.125 [main] TRACE o.h.e.d.AbstractFlushingEventListener - Scheduling collection removes/(re)creates/updates
11:02:56.126 [main] DEBUG o.h.e.d.AbstractFlushingEventListener - Flushed: 1 insertions, 0 updates, 0 deletions to 62 objects
11:02:56.126 [main] DEBUG o.h.e.d.AbstractFlushingEventListener - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
11:02:56.132 [main] TRACE o.h.e.d.AbstractFlushingEventListener - executing flush
11:02:56.132 [main] TRACE org.hibernate.jdbc.ConnectionManager - registering flush begin
11:02:56.132 [main] TRACE o.h.p.entity.AbstractEntityPersister - Inserting entity: [com.xyzcompany.foo.edoi.ejb.msw000.MSW000Rec#component[keyW000]{keyW000=F000 ADSUFC}]
11:02:56.132 [main] DEBUG org.hibernate.jdbc.AbstractBatcher - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
11:02:56.132 [main] DEBUG org.hibernate.SQL - insert into MSW000 (W000_DATA_REC, W000_FILE_FLAGS, KEY_W000) values (?, ?, ?)
11:02:56.132 [main] TRACE org.hibernate.jdbc.AbstractBatcher - preparing statement
11:02:56.132 [main] TRACE o.h.p.entity.AbstractEntityPersister - Dehydrating entity: [com.xyzcompany.foo.edoi.ejb.msw000.MSW000Rec#component[keyW000]{keyW000=F000 ADSUFC}]
11:02:56.132 [main] TRACE org.hibernate.type.StringType - binding ' ADSUFCA ' to parameter: 1
11:02:56.132 [main] TRACE org.hibernate.type.StringType - binding ' ' to parameter: 2
11:02:56.132 [main] TRACE org.hibernate.type.StringType - binding 'F000 ADSUFC' to parameter: 3
11:02:56.132 [main] DEBUG org.hibernate.jdbc.AbstractBatcher - Executing batch size: 1
11:02:56.133 [main] DEBUG org.hibernate.jdbc.AbstractBatcher - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
11:02:56.133 [main] TRACE org.hibernate.jdbc.AbstractBatcher - closing statement
11:02:56.133 [main] TRACE org.hibernate.jdbc.ConnectionManager - registering flush end
11:02:56.133 [main] TRACE o.h.e.d.AbstractFlushingEventListener - post flush
11:02:56.133 [main] DEBUG o.h.transaction.JDBCTransaction - commit
11:02:56.133 [main] TRACE org.hibernate.impl.SessionImpl - automatically flushing session
11:02:56.133 [main] TRACE org.hibernate.jdbc.JDBCContext - before transaction completion
11:02:56.133 [main] TRACE org.hibernate.impl.SessionImpl - before transaction completion
11:02:56.133 [main] DEBUG o.h.transaction.JDBCTransaction - committed JDBC Connection
11:02:56.133 [main] TRACE org.hibernate.jdbc.JDBCContext - after transaction completion
11:02:56.133 [main] DEBUG org.hibernate.jdbc.ConnectionManager - transaction completed on session with on_close connection release mode; be sure to close the session to release JDBC resources!
11:02:56.133 [main] TRACE org.hibernate.impl.SessionImpl - after transaction completion
11:02:56.133 [main] TRACE org.hibernate.impl.SessionImpl - closing session
11:02:56.133 [main] TRACE org.hibernate.jdbc.ConnectionManager - performing cleanup
11:02:56.133 [main] DEBUG org.hibernate.jdbc.ConnectionManager - releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
11:02:56.133 [main] TRACE o.h.c.DriverManagerConnectionProvider - returning connection to pool, pool size: 1
11:02:56.133 [main] TRACE org.hibernate.jdbc.JDBCContext - after transaction completion
11:02:56.133 [main] DEBUG org.hibernate.jdbc.ConnectionManager - transaction completed on session with on_close connection release mode; be sure to close the session to release JDBC resources!
11:02:56.134 [main] TRACE org.hibernate.impl.SessionImpl - after transaction completion
FINISH INSERT
When you call session.save(), hibernate will generate an INSERT SQL. This INSERT SQL will be appended to be issued to the DB during flushing (i.e session.flush()) .
During flushing, if hibernate.jdbc.batch_size is set to some non-zero value, Hibernate will use the batching feature introduced in the JDBC2 API to issue the batch insert SQL to the DB .
For example , if you save() 100 records and your hibernate.jdbc.batch_size is set to 50. During flushing, instead of issue the following SQL 100 times :
insert into TableA (id , fields) values (1, 'val1');
insert into TableA (id , fields) values (2, 'val2');
insert into TableA (id , fields) values (3, 'val3');
.........................
insert into TableA (id , fields) values (100, 'val100');
Hiberate will group them in batches of 50 , and only issue 2 SQL to the DB, like this:
insert into TableA (id , fields) values (1, 'val1') , (2, 'val2') ,(3, 'val3') ,(4, 'val4') ,......,(50, 'val50')
insert into TableA (id , fields) values (51, 'val51') , (52, 'val52') ,(53, 'val53') ,(54, 'val54'),...... ,(100, 'val100')
Please note that Hibernate would disable insert batching at the JDBC level transparently if the primary key of the inserting table isGenerationType.Identity.
From your log: you save() only one record and then flush(), so there is only one appending INSERT SQL to be processed for every flush. That's why Hibernate cannot help you to batch inserting as there is only one INSERT SQL to be processed. You should save() up to the certain amount of records before calling flush() instead of calling flush() for every save().
The best practise of batch inserting is something like this:
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
for ( int i=0; i<888888; i++ ) {
TableA record = new TableA();
record.setXXXX();
session.save(record)
if ( i % 50 == 0 ) { //50, same as the JDBC batch size
//flush a batch of inserts and release memory:
session.flush();
session.clear();
}
}
tx.commit();
session.close();
You save and flush the records batch by batch. In the end of each batch you should clear the persistence context to release some memory to prevent memory exhaustion as every persistent object is placed into the first level cache (your JVM's memory). You could also disable the second-level cache to reduce the unnecessary overhead.
Reference:
Official Hibernate Documentation : Chapter 14. Batch processing
Hibernate Batch Processing – Why you may not be using it. (Even if you think you are)
If you must use hibernate for huge batch jobs StatelessSession is the way to go. It strips things down to the most basic converting-objects-to-SQL-statements mapping and eliminates all of the overhead of the ORM features you're not using when just cramming rows into the DB wholesale.
It would also be much easier to make suggestions on your actual code than the log :)
11:02:56.133 [main] DEBUG o.h.transaction.JDBCTransaction - commit
This is saying that the database is committing after every insert. Ensure you are not committing your transaction / closing your session inside the insert loop. Do this once at the end instead.