I'm currently working with Springboot. now I want to query data by Java.util.date via JpaRepository and I have the following code in my interface.
List<MyEnity> findByDate(Date date);
I use Java.util.date and I have a personal reason that I couldn't change to java.time. I've ensured that
MyEntity Class in date field has TemporalType.DATE like this
#Temporal(TemporalType.DATE) private Date date;
and also the date field in MySQL is also date type
enter image description here
I tried to use the findByDate(Date date) method above and the date paramter in the method is obviously exist in my database but I always get an Empty List...
The other methods like findByName(String name) or findAll() work just fine.
I've tried to log the SQL statement from hibernate and I found that the binding parameter [DATE] might be in a different format? in my db is 'yyyy-mm-dd'
here is a log where I query with id and date. and at the bottom of the log I notice that the Id is binded with query statement, but date won't
2563-04-10 12:18:54.649 [restartedMain] INFO o.s.b.d.a.ConditionEvaluationDeltaLoggingListener - Condition evaluation unchanged
2563-04-10 12:19:03.241 [http-nio-8080-exec-2] INFO o.a.c.c.C.[.[.[/api/productionplan] - Initializing Spring DispatcherServlet 'dispatcherServlet'
2563-04-10 12:19:03.282 [http-nio-8080-exec-2] INFO o.s.web.servlet.DispatcherServlet - Initializing Servlet 'dispatcherServlet'
2563-04-10 12:19:03.307 [http-nio-8080-exec-2] INFO o.s.web.servlet.DispatcherServlet - Completed initialization in 8 ms
2563-04-10 12:19:03.346 [http-nio-8080-exec-2] DEBUG org.hibernate.SQL -
select
planibtout0_.planibtoutid as planibto1_23_,
planibtout0_.ibtqty as ibtqty2_23_,
planibtout0_.finisheddate as finished3_23_,
planibtout0_.finishedshiftid as finished4_23_,
planibtout0_.itemid as itemid6_23_,
planibtout0_.itemclassid as itemclas5_23_,
planibtout0_.planfinishedgoodid as planfini7_23_,
planibtout0_.planibtoutlotid as planibto8_23_,
planibtout0_.planqty as planqty9_23_,
planibtout0_.producerstoreid as produce10_23_,
planibtout0_.sellerstoreid as sellers11_23_,
planibtout0_.updateat as updatea12_23_,
planibtout0_.updateby as updateb13_23_
from
planibtout planibtout0_
where
planibtout0_.producerstoreid=1117
and planibtout0_.finisheddate=?
2563-04-10 12:19:03.359 [http-nio-8080-exec-2] TRACE o.h.type.descriptor.sql.BasicBinder - binding parameter [1] as [DATE] - [Tue Apr 15 00:00:00 ICT 1477]
2563-04-10 12:19:03.363 [http-nio-8080-exec-2] INFO c.n.t.t.s.c.SellerStoreController - -Data Not Found- No record found in database
here is my .yml properties
server:
port: 8080
servlet:
context-path: /api/xxx/
spring:
datasource:
url: jdbc:mysql://localhost:3306/xxx?useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=UTC
driverClassName: com.mysql.cj.jdbc.Driver
username: xxx
password:
continueOnError: false
maximum-pool-size: 20
minimum-idle: 0
idle-timeout: 10000
connection-timeout: 10000
max-lifetime: 10000
auto-commit: true
jpa:
show-sql: false
hibernate:
ddlAuto: none
properties:
hibernate:
dialect: org.hibernate.dialect.MySQLDialect
format_sql: true
startDayInWeek: 2
logging:
level:
com.zaxxer.hikari.HikariConfig: DEBUG
com.ntt.th: DEBUG
pattern:
console: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"
Actually, there is no problem with Date binding that why query executed perfectly.
May be problem is Application Timezone and Database timezone is not matching.
You are sending DATE with IndoChina Timezone(ICT) Tue Apr 15 00:00:00 ICT 1477 but you are using serverTimezone=UTC(In JDBC Url) for database which means you are using UTC Timezone for Database.
So, you can change the timezone for database using serverTimezone=ICT to use IndoChina Timezone(ICT)
Related
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 is from Kerberos sample app found at https://github.com/spring-projects/spring-security-kerberos/tree/master/spring-security-kerberos-samples/sec-server-win-auth corresponding to http://docs.spring.io/spring-security-kerberos/docs/1.0.1.RELEASE/reference/htmlsingle/#samples-sec-server-win-auth.
All I’m doing is modifying the src/main/resources/application.yml to fit my system and going back and forth between creating SPNs and Keytab files.
My spring application seems to be starting fine. Below is the Kerberos config that comes through the console output.
Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is /etc/client-server.keytab refreshKrb5Config is false principal is HTTP/client-server.example.org#REALM tryFirstPass is false useFirstPass is false storePass is false clearPass is false
principal is HTTP/client-server.example.org#REALM
Will use keytab
Commit Succeeded
So I can see that the client app has accepted my settings so far. Then I try to access client-server:8080/hello through chrome on another machine. The first error I get is Acces is denied (user is anonymous). Which is supposed to redirect to the authentication entry point. Then I get the following, ending with “No key to store”
[nio-8080-exec-4] w.a.SpnegoAuthenticationProcessingFilter : Received Negotiate Header for request client-server:8080/favicon.ico: Negotiate YIIHZAYGKwYBBQUCoIIHWDCCB1SgMDAuBgk……./9AdsoFH2ya7C
[nio-8080-exec-4] o.s.s.authentication.ProviderManager : Authentication attempt using org.springframework.security.kerberos.authentication.KerberosServiceAuthenticationProvider
[nio-8080-exec-4] .a.KerberosServiceAuthenticationProvider : Try to validate Kerberos Token
[nio-8080-exec-4] .a.KerberosServiceAuthenticationProvider : Succesfully validated myUsername#REALM
[nio-8080-exec-4] o.s.s.l.s.FilterBasedLdapUserSearch : Searching for user 'myUsername#REALM', with user search [ searchFilter: '', searchBase: 'DC=xxxxx', scope: subtree, searchTimeLimit: 0, derefLinkFlag: false ]
Debug is true storeKey true useTicketCache true useKeyTab true doNotPrompt true ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is HTTP/client-server.example.org#REALM tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Acquire TGT from Cache
Principal is HTTP/client-server.example.org#REALM
2015-11-27 11:38:47.906 DEBUG 3183 --- [nio-8080-exec-4] w.c.HttpSessionSecurityContextRepository : SecurityContext is empty or contents are anonymous - context will not be stored in HttpSession.
2015-11-27 11:38:47.906 DEBUG 3183 --- [nio-8080-exec-4] s.s.w.c.SecurityContextPersistenceFilter : SecurityContextHolder now cleared, as request processing completed
2015-11-27 11:38:47.912 ERROR 3183 --- [nio-8080-exec-4] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception
org.springframework.ldap.AuthenticationException: No key to store; nested exception is javax.naming.AuthenticationException: No key to store [Root exception is javax.security.auth.login.LoginException: No key to store]
Now it appears that the app is able to validate my user, but I have no idea if it could find my user info.
Viewing the source for Krb5LoginModule.java at cr.openjdk.java.net/~weijun/7201053/webrev.00/raw_files/new/src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java, you can find the login exception, no key to store, by simple search. The code says that my ktab (keytab I’m guessing), is null. Strangely enough, the console output does say that when I try to navigate using the browser, that the keytab is null, even though it wasn’t when I started up the application.
Does anyone know why my keytab is going null when I have a user try to access my application? Or is something else wrong with my application or system configuration?
I ran into a similar issue, and the root cause was actually a corrupt key created by kinit. The solution was to delete the cache (both under /tmp/kbr5cc_[UID], and in the value set by ticketCache="/home/solr/cache" in the JAAS config file, and NOT to run kinit before starting the app.
To find what was going on, I added the following flag to the JVM: -Dsun.security.krb5.debug=true
I saw that the key had the start and end time set to the epoch date:
>>>DEBUG <CCacheInputStream> key type: 0
>>>DEBUG <CCacheInputStream> auth time: Thu Jan 01 00:00:00 UTC 1970
>>>DEBUG <CCacheInputStream> start time: null
>>>DEBUG <CCacheInputStream> end time: Thu Jan 01 00:00:00 UTC 1970
>>>DEBUG <CCacheInputStream> renew_till time: null
So I slept on this for the weekend. Strangely enough, it looked like the solution now works since the TGT acquired from cache was past renewal time. I don’t really know how it all works, but now the keytab is accepted when my user navigates to the application.
The only problem left was the Ldap couldn’t find my user details due to a mismatch between the Kerberos username used to query LDAP, so I had to re-implement org.springframework.security.ldap.search.FilterBasedLdapUserSearch to modify the username. Then the solution worked.
I'm working on an Integrator for Hibernate (background on Integrators: https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch14.html#objectstate-decl-security) that by using listeners is supposed to take my data from how it's stored in the DB and convert it into a different form for processing at runtime. This works great when saving the data using .persist() however there's an odd behavior involving transactions. The following code is from Hibernate's own quickstart tutorial code:
// now lets pull events from the database and list them
entityManager = entityManagerFactory.createEntityManager();
entityManager.getTransaction().begin();
List<Event> result = entityManager.createQuery( "from Event", Event.class ).getResultList();
for ( Event event : result ) {
System.out.println( "Event (" + event.getDate() + ") : " + event.getTitle() );
}
entityManager.getTransaction().commit();
entityManager.close();
Notice the unusual transaction begin/commit wrapping the query to select the data. Running this gives the following output after the query completes:
01:01:59.111 [main] DEBUG org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(175) - committing
01:01:59.112 [main] DEBUG org.hibernate.event.internal.AbstractFlushingEventListener.prepareEntityFlushes(149) - Processing flush-time cascades
01:01:59.112 [main] DEBUG org.hibernate.event.internal.AbstractFlushingEventListener.prepareCollectionFlushes(189) - Dirty checking collections
01:01:59.114 [main] DEBUG org.hibernate.event.internal.AbstractFlushingEventListener.logFlushResults(123) - Flushed: 0 insertions, 2 updates, 0 deletions to 2 objects
01:01:59.114 [main] DEBUG org.hibernate.event.internal.AbstractFlushingEventListener.logFlushResults(130) - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
01:01:59.114 [main] DEBUG org.hibernate.internal.util.EntityPrinter.toString(114) - Listing entities:
01:01:59.114 [main] DEBUG org.hibernate.internal.util.EntityPrinter.toString(121) - org.hibernate.tutorial.em.Event{date=2015-07-28 01:01:57.776, id=1, title=Our very first event!}
01:01:59.114 [main] DEBUG org.hibernate.internal.util.EntityPrinter.toString(121) - org.hibernate.tutorial.em.Event{date=2015-07-28 01:01:58.746, id=2, title=A follow up event}
01:01:59.115 [main] DEBUG org.hibernate.SQL.logStatement(109) - update EVENTS set EVENT_DATE=?, title=? where id=?
Hibernate: update EVENTS set EVENT_DATE=?, title=? where id=?
01:01:59.119 [main] DEBUG org.hibernate.SQL.logStatement(109) - update EVENTS set EVENT_DATE=?, title=? where id=?
Hibernate: update EVENTS set EVENT_DATE=?, title=? where id=?
01:01:59.120 [main] DEBUG org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doCommit(113) - committed JDBC Connection
01:01:59.120 [main] DEBUG org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.close(201) - HHH000420: Closing un-released batch
01:01:59.121 [main] DEBUG org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.releaseConnection(246) - Releasing JDBC connection
01:01:59.121 [main] DEBUG org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.releaseConnection(264) - Released JDBC connection
01:01:59.121 [main] DEBUG org.hibernate.internal.SessionFactoryImpl.close(1339) - HHH000031: Closing
It appears that since the Integrator does a modification on the entity in question it gets marked as "dirty" and upon committing this odd transaction, it bypasses my event listeners and writes the value back in the wrong format! I did some digging in the code and it turns out that org.hibernate.event.internal.AbstractFlushingEventListener.flushEntities(FlushEvent, PersistenceContext) gets called above and tries to get listeners for EventType.FLUSH_ENTITY. Unfortunately a listener added for this EventType is never called in my Integrator. How can I write my Integrator to behave correctly in this case so that I can "undo" the conversion that has happened with my entities at runtime and not flush the wrong value out?
Ultimately the problem was due to the EventTypes of the event listeners added with the EventListenerRegistry. What worked was using EventType.POST_LOAD for all the read operations combined with EventType.PRE_UPDATE and EventType.PRE_INSERT for writes that call a helper method for handling both the same way.
To prevent unneeded writes after making your entity updates it's a good idea to reset the data used for tracking if the entity is dirty in EntityEntry called loadedState. This is a private field in Hibernate 4 so you'll need to use Reflection, however in Hibernate 5 it's available via the getLoadedState() method. One more gotcha is you need to update values of the "state" used when actually flushing the values to the database by the PreInsertEvent and PreUpdateEvent which can be retrieved from the getState() method defined in each.
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.
I'm trying to use Hibernate to persist a class that looks like this:
public class Item implements Serializable, Comparable<Item> {
// Item id
private Integer id;
// Description of item in inventory
private String description;
// Number of items described by this inventory item
private int count;
//Category item belongs to
private String category;
// Date item was purchased
private GregorianCalendar purchaseDate;
public Item() {
}
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
public String getDescription() {
return description;
}
public void setDescription(String description) {
this.description = description;
}
public int getCount() {
return count;
}
public void setCount(int count) {
this.count = count;
}
public String getCategory() {
return category;
}
public void setCategory(String category) {
this.category = category;
}
public GregorianCalendar getPurchaseDate() {
return purchaseDate;
}
public void setPurchasedate(GregorianCalendar purchaseDate) {
this.purchaseDate = purchaseDate;
}
My Hibernate mapping file contains the following:
<property name="puchaseDate" type="java.util.GregorianCalendar">
<column name="purchase_date"></column>
</property>
When I try to run, I get error messages indicating there is no getter function for the purchaseDate attribute:
577 [main] INFO org.hibernate.connection.DriverManagerConnectionProvider - Using Hibernate built-in connection pool (not for production use!)
577 [main] INFO org.hibernate.connection.DriverManagerConnectionProvider - Hibernate connection pool size: 20
577 [main] INFO org.hibernate.connection.DriverManagerConnectionProvider - autocommit mode: false
592 [main] INFO org.hibernate.connection.DriverManagerConnectionProvider - using driver: com.mysql.jdbc.Driver at URL: jdbc:mysql://localhost:3306/home_inventory
592 [main] INFO org.hibernate.connection.DriverManagerConnectionProvider - connection properties: {user=root, password=****}
1078 [main] INFO org.hibernate.cfg.SettingsFactory - RDBMS: MySQL, version: 5.1.45
1078 [main] INFO org.hibernate.cfg.SettingsFactory - JDBC driver: MySQL-AB JDBC Driver, version: mysql-connector-java-5.1.12 ( Revision: ${bzr.revision-id} )
1103 [main] INFO org.hibernate.dialect.Dialect - Using dialect: org.hibernate.dialect.MySQLDialect
1107 [main] INFO org.hibernate.engine.jdbc.JdbcSupportLoader - Disabling contextual LOB creation as JDBC driver reported JDBC version [3] less than 4
1109 [main] INFO org.hibernate.transaction.TransactionFactoryFactory - Using default transaction strategy (direct JDBC transactions)
1110 [main] INFO org.hibernate.transaction.TransactionManagerLookupFactory - No TransactionManagerLookup configured (in JTA environment, use of read-write or transactional second-level cache is not recommended)
1110 [main] INFO org.hibernate.cfg.SettingsFactory - Automatic flush during beforeCompletion(): disabled
1110 [main] INFO org.hibernate.cfg.SettingsFactory - Automatic session close at end of transaction: disabled
1110 [main] INFO org.hibernate.cfg.SettingsFactory - JDBC batch size: 15
1110 [main] INFO org.hibernate.cfg.SettingsFactory - JDBC batch updates for versioned data: disabled
1111 [main] INFO org.hibernate.cfg.SettingsFactory - Scrollable result sets: enabled
1111 [main] INFO org.hibernate.cfg.SettingsFactory - JDBC3 getGeneratedKeys(): enabled
1111 [main] INFO org.hibernate.cfg.SettingsFactory - Connection release mode: auto
1111 [main] INFO org.hibernate.cfg.SettingsFactory - Maximum outer join fetch depth: 2
1111 [main] INFO org.hibernate.cfg.SettingsFactory - Default batch fetch size: 1
1111 [main] INFO org.hibernate.cfg.SettingsFactory - Generate SQL with comments: disabled
1111 [main] INFO org.hibernate.cfg.SettingsFactory - Order SQL updates by primary key: disabled
1111 [main] INFO org.hibernate.cfg.SettingsFactory - Order SQL inserts for batching: disabled
1112 [main] INFO org.hibernate.cfg.SettingsFactory - Query translator: org.hibernate.hql.ast.ASTQueryTranslatorFactory
1113 [main] INFO org.hibernate.hql.ast.ASTQueryTranslatorFactory - Using ASTQueryTranslatorFactory
1113 [main] INFO org.hibernate.cfg.SettingsFactory - Query language substitutions: {}
1113 [main] INFO org.hibernate.cfg.SettingsFactory - JPA-QL strict compliance: disabled
1113 [main] INFO org.hibernate.cfg.SettingsFactory - Second-level cache: enabled
1113 [main] INFO org.hibernate.cfg.SettingsFactory - Query cache: disabled
1113 [main] INFO org.hibernate.cfg.SettingsFactory - Cache region factory : org.hibernate.cache.impl.NoCachingRegionFactory
1113 [main] INFO org.hibernate.cfg.SettingsFactory - Optimize cache for minimal puts: disabled
1114 [main] INFO org.hibernate.cfg.SettingsFactory - Structured second-level cache entries: disabled
1117 [main] INFO org.hibernate.cfg.SettingsFactory - Echoing all SQL to stdout
1118 [main] INFO org.hibernate.cfg.SettingsFactory - Statistics: disabled
1118 [main] INFO org.hibernate.cfg.SettingsFactory - Deleted entity synthetic identifier rollback: disabled
1118 [main] INFO org.hibernate.cfg.SettingsFactory - Default entity-mode: pojo
1118 [main] INFO org.hibernate.cfg.SettingsFactory - Named query checking : enabled
1118 [main] INFO org.hibernate.cfg.SettingsFactory - Check Nullability in Core (should be disabled when Bean Validation is on): enabled
1151 [main] INFO org.hibernate.impl.SessionFactoryImpl - building session factory
org.hibernate.HibernateException: Unable to instantiate default tuplizer [org.hibernate.tuple.entity.PojoEntityTuplizer]
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructTuplizer(EntityTuplizerFactory.java:110)
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructDefaultTuplizer(EntityTuplizerFactory.java:135)
at org.hibernate.tuple.entity.EntityEntityModeToTuplizerMapping.<init>(EntityEntityModeToTuplizerMapping.java:80)
at org.hibernate.tuple.entity.EntityMetamodel.<init>(EntityMetamodel.java:323)
at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:475)
at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:133)
at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:84)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:295)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1385)
at service.HibernateSessionFactory.currentSession(HibernateSessionFactory.java:53)
at service.ItemSvcHibImpl.generateReport(ItemSvcHibImpl.java:78)
at service.test.ItemSvcTest.testGenerateReport(ItemSvcTest.java:226)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.hibernate.tuple.entity.EntityTuplizerFactory.constructTuplizer(EntityTuplizerFactory.java:107)
... 29 more
Caused by: org.hibernate.PropertyNotFoundException: Could not find a getter for puchaseDate in class domain.Item
at org.hibernate.property.BasicPropertyAccessor.createGetter(BasicPropertyAccessor.java:328)
at org.hibernate.property.BasicPropertyAccessor.getGetter(BasicPropertyAccessor.java:321)
at org.hibernate.mapping.Property.getGetter(Property.java:304)
at org.hibernate.tuple.entity.PojoEntityTuplizer.buildPropertyGetter(PojoEntityTuplizer.java:299)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.<init>(AbstractEntityTuplizer.java:158)
at org.hibernate.tuple.entity.PojoEntityTuplizer.<init>(PojoEntityTuplizer.java:77)
... 34 more
I'm new to Hibernate, so I don't know all the ins and outs, but I do have the getter and setter for the purchaseDate attribute. I don't know what I'm missing here - does anyone else?
It came to me once without any typos. I've added javassist.jar to classpath and it solved the problem.
Further on down the stack trace, it says this:
missing a getter for puchaseDate
You might want to check for typos ;) You're missing an R and setPurchasedate should be setPurchaseDate
It looks like the problem is probably in the capitalization: setPurchasedate() should be setPurchaseDate() (with a capital "D").
If it can help someone:
In my case there were errors in my mapping files. Classes were not referenced by their full package names. I did this mistake because I generated the mappings when my bean classes belonged to the default package (hence no package name; e.g.: Order instead of com.mypackage.Order) and then I moved my bean classes to package (in the example com.mypackage). Unfortunately mapping files did not changed accordingly with the new package definition.
My hint is redo Hibernate reverse engineering and see what it produces, comparing it with your current mapping files.
Pay attention to method name,It is case sensitive!
In my case,it could not recognize getter very well; my property name was uId and I used getUId name for getter name and when I changed it to getuId problem solved!
I included java assit.jar and it worked
<dependency>
<groupId>javassist</groupId>
<artifactId>javassist</artifactId>
<version>3.12.1.GA</version>
</dependency>
I experienced the
Unable to instantiate default tuplizer [org.hibernate.tuple.entity.PojoEntityTuplizer]
because I had a momentary lapse of donkeyness when renaming a field on a POJO that I had previously mapped.
I changed the Java attribute name with my trusty IDE refactor hotkey, which does not also change the getter & setter method names. I changed the getter (because it caught my attention with its #Column annotation that I also needed to address because the table column name was changing).
I neglected, however, to change the setter, and that was the cause of the error.