You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After our biweekly call last week, it has come to attention that during GlassFish deployment, Java Persistence API tries to create tables in Postgres and will still do so even if the tables exist. This has two consequences:
If we redeploy the application, thousands of unnecessary warnings will be in the log
Startup time will be longer even if it's the second time the installation is run.
A preferred solution could be removing the create-tables field in persistence.xml and setting up the tables prior to asadmin deploy dataverse.war. In OpenShift, upon scaling up the GlassFish application, the second instance deploys faster than the first instance by roughly 25 seconds (2 minutes 15 seconds vs 2 minutes 40).
(I'll call the 1st glassfish pod the parent and any pod after that children pod)
Performance could potentially be better (all children runs faster than the parent by more than 25 seconds) if they don't try to recreate tables that are already there.
The text was updated successfully, but these errors were encountered:
thaorell
changed the title
Mobilizing "create-tables" in persistence.xml and removing unnecessary errors when table is created
Mobilizing "create-tables" in persistence.xml and removing unnecessary errors when table is re-created
Aug 3, 2018
After our biweekly call last week, it has come to attention that during GlassFish deployment, Java Persistence API tries to create tables in Postgres and will still do so even if the tables exist. This has two consequences:
A preferred solution could be removing the create-tables field in persistence.xml and setting up the tables prior to
asadmin deploy dataverse.war
. In OpenShift, upon scaling up the GlassFish application, the second instance deploys faster than the first instance by roughly 25 seconds (2 minutes 15 seconds vs 2 minutes 40).(I'll call the 1st glassfish pod the parent and any pod after that children pod)
Performance could potentially be better (all children runs faster than the parent by more than 25 seconds) if they don't try to recreate tables that are already there.
The text was updated successfully, but these errors were encountered: