I have an IntelliJ project using Spring MVC and with Hibernate FlushMode set to auto as default.
The problem is: when I try to delete an object from the db, using the web interface, it works fine, but after the third time I do that, the interface becomes not responsive (even though Hibernate receives the command to delete that certain object with that certain ID) and I have to reboot my WildFly server.
Any idea where I can change that? Is there a way to set it in a configuration file or I have to invoke a method to set it? And even if the problem is the FlushMode itself.
Regards
UPDATE: After testing several things, I think I finally found the root of the problem. If I access the db for more than three times consecutively, the server becomes unresponsive. How can I overcome this?
UPDATE#2: I found that the problem was that in the Dao the connection was opened but never closed (there wasn't a line "session.close()" just to be clear). And that was the reason After three pooling from the db, was it either to add items, delete them or just get infos, the server became unresponsive. Now everything works perfectly!
I actually didn't get your question properly.
The third time you try to delete something from your frontend, the web page gets stuck? The third time you make a delete request is the request stuck with hibernate? Could be a little clear about what actually is happening/or what issue you are facing.
To answer your question - how to setFlushMode in hibernate:
In case you using EntityManager -> entityManager.setFlushMode(FlushModeType.) -> JPA supports AUTO and COMMIT
In case you using SessionFactory:
sessionFactory.setHibernateFlushMode(FlushMode.) -> From hibernate 5
OR
sessionFactory.setFlushMode(FlushMode.) -> Before Hibernate 5
(NOTE: Please check the docs for accurate version of hibernate from which setFlushMode is deprecated.
Hibernate supports 4 modes of flush -> AUTO/COMMIT/ALWAYS/MANUAL
Related
I am having a problem with the Oracle Rest Data Services (short ORDS) and I can't find a solution.
The Problem is as follows:
We are using ORDS via a TomCat Webserver and I have 2 Endpoints defined, one to Update a dataset and one to get all datasets from this table.
If I update the value via my Endpoint the change is written in the Table, but if I try to get the table with this change ORDS only response with the old not changed table. After a certain period of Time while constantly trying to get the change it repondes with the expected values. (happens after max 1 minute, can be earlier).
Because of this behaviour I accused some type of caching, but I cant find no configuration in the oracle database or on the TomCat.
Another Point for this theory was that I logged what happens in my GET procedure and found that only the one request with the correct values gets logged, like the others didnt even happen ..
The Request giving me the old value are coming back in the 4-8 ms range while the request with the correct data is in the 100-200 ms.
Ty for your help :)
I tried logging what happens, but I got that only the request with the fresh values was logged.
I tried to restart the TomCat Webserver to make sure that the cache is cleared, but this didnt fix the Problem
I searched for a configuration in ORDS or oracle where a cache would be defined, but it was never set.
I tried to set the value via a SQL update and not an endpoint, but even here I get the change only delayed
Do you have a full overview of the communication path? Maybe there is a proxy between?
When the TomCat has no caching configuration and you restartet the webserver during your tests and still have the same issue, then there is maybe more...
Kind regards
M-Achilles
We have a Spring boot application that has been in production for a while. We use Flyway to manage database migrations. I just upgraded to Spring boot 2.5.4 from 2.4.5 which brings with it an upgrade to Flyway 7.7.3.
When executing all the migrations in a fresh local environment, the migration now fails due to a syntax issue with this comment:
---*********************---
-- ** AUDITING TABLES ** --
---*********************---
I imagine this won't be an issue in environments which have already executed this migration but what is the best way to fix this for new environments with a fresh database given that the original file cannot be edited due to checksum comparison on migration?
My current versioning just includes a major version i.e. V2, V3 etc. My thinking is to get rid of V2 (the script with the issue) and introduce V2.1 which would be an exact copy of V2 with the erroneous comment section removed. I would then set both ignoreMissingMigrations and ignoreIgnoredMigrations to true
Does this sound like the right way to solve this?
Thanks in advance.
Changing the script and then executing flyway repair would be the ideal solution - this would rectify the checksums.
Assuming this option is not available for some reason (it would be helpful to know what that is in case we can fix it!), the above sounds correct. ignoreMissingMigrations means your old deployments won't object to V2 not being there, and ignoreIgnoredMigrations means they won't object to V2.1 being present. The downside is that these ignores may not be valid in the longer term - so they won't, for example, catch a later script that goes missing unintentionally.
Every time I try to start "Spring Boot Dashboard" from VSCode I get an error while using the following command.
spring.jpa.hibernate.ddl-auto=update (Doesn't Work)
However, I managed to find this line here on stack overflow that made it work. The problem is I don't know the difference and how will it impact my production.
spring.jpa.hibernate.hbm2ddl.auto=update (Works)
Any sort of help would be more than appreciated.
From this Link
spring.jpa.hibernate.ddl-auto This is actually a shortcut for the "hibernate.hbm2ddl.auto" property.
Defaults to "create-drop" when using an embedded database and no schema manager was detected. Otherwise, defaults to "none".
From this Stackoverflow Link
In production, it's often highly recommended you use none or simply don't specify this property. That is because it's common practice for DBAs to review migration scripts for database changes, particularly if your database is shared across multiple services and applications.
Here is how setup looks like:
ApplicationServer - GlassFish
Database Server - Oracle 10g2
Persistance Library - EclipseLink
Faces Framework - IceFaces
My Problem is that everytime I change the database connection the application/eclipselink stops working, failing to find the Persistance Unit.
After loosing a whole day trying to figure it out. I decided to delete all the information about connections and persistance units and use only one new created.
Building the project was not a problem, but running it I get an error, pointing that the there is a validationexception and a persistance unit with a given name was not found. That name is deleted and is't descriped in the persistance.xml nor in the sun-resources.xml. There is no such entry in the Services in Netbeans.
Have you seen such an error, and how can I make sure, that netbeans doesn't store information on places I can't reach from the IDE? How is it so that my application is looking for something that isn't listed anywhere...
Okay next time I have to think more, instead of asking the question here. So my problem was the cache directory of Netbeans 6.9.1.
Deleted the cache directory and everything started working again.
I hope that this problem is fixed in the next releases. it can be real pain in ... :)
I've been reading about implicitCachingEnabled and MaxStatements with the oracle jdbc driver.
I've tried adding implicitCachingEnabled="true" into the server.xml for the datasource definition but it makes no difference.
I've also noted other posts admittedly from a long time ago, where people have failed to get this setting to work simply by setting it in the tomcat config files.
So just on the offchance someone has it working, is there a trick to it?
In the mean time i'll investigate whether it's possible or not to do this via code, but we're using JPA so i'm not sure how that'll work!
Thanks,
Dan
Try to set the value OracleConnection.setStatementCacheSize () instead of MaxStatements
http://www.stanford.edu/dept/itss/docs/oracle/10g/java.101/b10979/stmtcach.htm