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.
pdurbin
commented
2 years ago
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.