Sometimes the only way things ever got fixed is because people became uncomfortable.
Tim Holloway wrote:I think it may be because you've configured Hibernate in "create-drop" mode. This is a useful mode for testing, since it will automatically construct a schema for you when the application starts. But if I'm not mistaken, it also DELETES the schema when the application terminates.
Sometimes the only way things ever got fixed is because people became uncomfortable.
Tim Holloway wrote:The other side of "create-drop" is create. Since your previous tests were doing drops, you would have to re-create the schema manually. If you haven't done that, then any attempt to insert data would fail for lack of a defined database table to put the data into.
Anatolii Stasuykevich wrote:
I try to use another method for creating using manually creation EntityManager in the main method and it save data, but when I used @PersistenceContext injection for EntityManager it doesn't work.
...
Sometimes the only way things ever got fixed is because people became uncomfortable.
Roland Mueller wrote:
Anatolii Stasuykevich wrote:
I try to use another method for creating using manually creation EntityManager in the main method and it save data, but when I used @PersistenceContext injection for EntityManager it doesn't work.
I think the problem of unsaved record is related to the failure of committing the DB change(s) done during the transaction. Class BookService uses annotation javax.transaction.Transactional on class level and that should enclose the methods of BookService with an transaction. Thus, I cannot see any error in this and a transaction was started because Hibernate did not report any error with the INSERT.
I would first try to add some flush() after the persist() in line #8 in BookService. Not sure whether this helps.
Tim Holloway wrote:A thought.
This is a Wildfly webapp. Wildfly is a full-stack JEE server and that makes it different from partial-stack webapp servers like Tomcat.
Specifically, Wildfly is an EJB container. Unlike JPA webapps for Tomcat, you do not include Hibernate JARs in your WAR, because Hibernate is part of Wildfly itself. JPA is, after all a subset of EJB and EJB is part of the JEE full stack.
Basic JPA is convenient for non-EJB systems like stand-alone Java and Tomcat webapps, but it's built into EJB-capable servers like Wildfly, IBM WebSphere and Oracle WebLogic. So again, the WAR must be built and configured differently than it would for a Tomcat webapp. Otherwise you end up with library conflicts and unpredictable results.
I'd recommend looking at this: https://docs.jboss.org/author/display/WFLY10/JPA%20Reference%20Guide.html#91947210_JPAReferenceGuide-UpdateyourPersistence.xmlforHibernate5.0
Actually, I think there may be a newer version than that one, but it does point out some significant differences between Wildfly 5 and older JBoss servers.
Anatolii Stasuykevich wrote:
Got it. Thanks heh strange behavior for wildFly. Don't understand why wildFly doesn't dave data using JPA.
Sometimes the only way things ever got fixed is because people became uncomfortable.
Tim Holloway wrote:
Anatolii Stasuykevich wrote:
Got it. Thanks heh strange behavior for wildFly. Don't understand why wildFly doesn't dave data using JPA.
Because if you have 2 different copies of JPA running at the same time, results are unpredictable. Stuff can get routed to the wrong copy and lost.
That's why it is critical that you set up JPA webapps for Wildfly exactly according to the Wildfly instructions.
Sometimes the only way things ever got fixed is because people became uncomfortable.
Anatolii Stasuykevich wrote:
Yep, it didn't help. I pin logs logs
Sometimes the only way things ever got fixed is because people became uncomfortable.
Tim Holloway wrote:
Anatolii Stasuykevich wrote:
Yep, it didn't help. I pin logs logs
Please don't do that. Paste the log into the Ranch message editor so we can see it here.
Anatolii Stasuykevich wrote:
Tim Holloway wrote:
Anatolii Stasuykevich wrote:
Yep, it didn't help. I pin logs logs
Please don't do that. Paste the log into the Ranch message editor so we can see it here.
Okay, but I will split the log because it is too large for one slice.
Sometimes the only way things ever got fixed is because people became uncomfortable.
Tim Holloway wrote:You are using a very old MySQL driver. The current MySQL Connector version is version 8. Version 5 does not guarantee SQL 92 standard operation.
You also appear to still have the create/delete option set for your database.
I didn't see any actual JPA or JDBC activity in the log, so you may need to adjust your log settings as indicated in the link I provided earlier. It would be a good idea if you'd also print a log message before and after the persist() call in your code just to help highlight where the trouble happens.
Anatolii Stasuykevich wrote:
Tim Holloway wrote:You are using a very old MySQL driver. The current MySQL Connector version is version 8. Version 5 does not guarantee SQL 92 standard operation.
You also appear to still have the create/delete option set for your database.
I didn't see any actual JPA or JDBC activity in the log, so you may need to adjust your log settings as indicated in the link I provided earlier. It would be a good idea if you'd also print a log message before and after the persist() call in your code just to help highlight where the trouble happens.
When I removed the create statement I got the next error with the not found Book table. It is strange because I manually created this table and database and It should exist. It seems like persistence.xml don't map the data source on what I wrote in the file.
Anatolii Stasuykevich wrote:
Anatolii Stasuykevich wrote:
Tim Holloway wrote:You are using a very old MySQL driver. The current MySQL Connector version is version 8. Version 5 does not guarantee SQL 92 standard operation.
You also appear to still have the create/delete option set for your database.
I didn't see any actual JPA or JDBC activity in the log, so you may need to adjust your log settings as indicated in the link I provided earlier. It would be a good idea if you'd also print a log message before and after the persist() call in your code just to help highlight where the trouble happens.
When I removed the create statement I got the next error with the not found Book table. It is strange because I manually created this table and database and It should exist. It seems like persistence.xml don't map the data source on what I wrote in the file.
I am working on logging for JPA.
log wrote:
ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-1) Table "BOOK" not found; SQL statement:
insert into Book (description, title, unitCost, id) values (?, ?, ?, ?) [42102-197]
Sometimes the only way things ever got fixed is because people became uncomfortable.
Tim Holloway wrote:
log wrote:
ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-1) Table "BOOK" not found; SQL statement:
insert into Book (description, title, unitCost, id) values (?, ?, ?, ?) [42102-197]
OK, this looks like you turned off the create/delete Hibernate option, but you haven't manually created the "book" table before starting the webapp.
Sometimes the only way things ever got fixed is because people became uncomfortable.
Tim Holloway wrote:1. You're not pointing to the database that you think you're pointing to
OR
2. You did not capitalize "Book" properly. MySQL can be case-sensitive when it comes to table names.
...
Tim Holloway wrote:1. You're not pointing to the database that you think you're pointing to
OR
2. You did not capitalize "Book" properly. MySQL can be case-sensitive when it comes to table names.
Sometimes the only way things ever got fixed is because people became uncomfortable.