JPA: drop-and-create schema generation action failed

[hantsy]

I tried to update my sample application to the latest Helidon 2.2 from 1.3. But failed. The application failed to start.

Sample codes

Environment Details

• Helidon Version: 2.2
• Helidon MP
• JDK version: 11
• OS: Windows
• Docker version (if applicable): 3.0

Description

When setting the javax.persistence.schema-generation.database.action to drop-and-create, it did not work as expected.

The table generation failed and the application failed to start.

I attached a copy of the log from the console.

app.log

And in the Postgres database Docker console, there are some errors.

postgres_1  | 2020-12-24 11:42:27.444 UTC [73] STATEMENT:  CREATE TABLE comments (ID VARCHAR(255) NOT NULL, CONTENT VARCHAR(255), created_at VARCHAR(255), post_id VARCHAR(255), PRIMARY KEY (ID))
postgres_1  | 2020-12-24 11:42:27.456 UTC [73] ERROR:  current transaction is aborted, commands ignored until end of transaction block
postgres_1  | 2020-12-24 11:42:27.456 UTC [73] STATEMENT:  SELECT 1
postgres_1  | 2020-12-24 11:42:27.523 UTC [73] ERROR:  current transaction is aborted, commands ignored until end of transaction block
postgres_1  | 2020-12-24 11:42:27.523 UTC [73] STATEMENT:  INSERT INTO posts (ID, CONTENT, created_at, STATUS, TITLE) VALUES ($1, $2, $3, $4, $5)
postgres_1  | 2020-12-24 11:42:27.525 UTC [73] ERROR:  current transaction is aborted, commands ignored until end of transaction block
postgres_1  | 2020-12-24 11:42:27.525 UTC [73] STATEMENT:  SELECT 1
postgres_1  | 2020-12-24 11:46:10.519 UTC [89] ERROR:  table "posts" does not exist
postgres_1  | 2020-12-24 11:46:10.519 UTC [89] STATEMENT:  DROP TABLE posts CASCADE
postgres_1  | 2020-12-24 11:46:10.534 UTC [89] ERROR:  current transaction is aborted, commands ignored until end of transaction block
postgres_1  | 2020-12-24 11:46:10.534 UTC [89] STATEMENT:  SELECT 1
postgres_1  | 2020-12-24 11:46:10.553 UTC [89] ERROR:  current transaction is aborted, commands ignored until end of transaction block
postgres_1  | 2020-12-24 11:46:10.553 UTC [89] STATEMENT:  DROP TABLE comments CASCADE
postgres_1  | 2020-12-24 11:46:10.565 UTC [89] ERROR:  current transaction is aborted, commands ignored until end of transaction block
postgres_1  | 2020-12-24 11:46:10.565 UTC [89] STATEMENT:  SELECT 1
postgres_1  | 2020-12-24 11:46:10.573 UTC [89] ERROR:  current transaction is aborted, commands ignored until end of transaction block
postgres_1  | 2020-12-24 11:46:10.573 UTC [89] STATEMENT:  DROP TABLE posts CASCADE
postgres_1  | 2020-12-24 11:46:10.576 UTC [89] ERROR:  current transaction is aborted, commands ignored until end of transaction block
postgres_1  | 2020-12-24 11:46:10.576 UTC [89] STATEMENT:  SELECT 1

There is a CREATE TABLE comments (ID VARCHAR(255) NOT NULL, CONTENT VARCHAR(255), created_at VARCHAR(255), post_id VARCHAR(255), PRIMARY KEY (ID)) in the log,

The LocalDateTime is converted to varchar, which is also not my expectation.

[ljnelson]

@hantsy Does this work if you add <property name="eclipselink.deploy-on-startup" value="true"/> to your persistence.xml?

The root cause is that your first operation on the EntityManager occurs within a JTA transaction. This should be fine, but here it causes the DDL generation (the deployment) to occur during that transaction as well. When the DROP TABLE DDL statement is issued against a non-existent table, it appears that the transaction rolls back (as it should in general, but maybe our integration is not doing something that is normally done in application servers here). Then Eclipselink ignores the error, as it should—it's harmless—and sends a CREATE TABLE right afterwards, but the current transaction is in a rolled-back state, so you get another exception.

To be clear: this is definitely a bug in some way, because this shouldn't be happening. The DDL operation should ideally happen in such a way that it does not impact the current user transaction, if any.

However, I'm curious if it can be worked around. One way to accomplish this is to instruct Eclipselink to deploy on startup, which the persistence.xml property I've mentioned above will do. I would be interested to see if that works around the problem (it does not fix it). This would mean that Eclipselink would do all the DDL work outside of a JTA transaction before any user code executes.

Regarding type conversion, Helidon does no type conversion of its own, but I'll see if I can figure out if perhaps something about the dialect or driver you're using is responsible.

[ljnelson]

I see from your sample project that you do have that property set. It seems like perhaps it is not being seen or read, because I think deployment should be happening considerably earlier than this if it were. I'll look more at this, though this is under the control of Eclipselink, not Helidon.

[hantsy]

@ljnelson You have to know this sample is upgraded from an earlier working version. I hope the persistence.xml config can be optional, make all JPA properties can be configured in the application.yaml file.

[ljnelson]

Returning to the issue at hand, there was a lot of work in the transactions/JTA area that solved other problems. I'm guessing that in fixing those problems, lazy initialization of the EntityManagerFactory ended up itself being problematic.

If you have a feature request, do kindly file an issue about it; we're happy to help.

[ljnelson]

I've confirmed that eagerly "inflating" the EntityManagerFactory client proxies at startup fixes the transaction problem. Now when I run your sample code against an appropriately configured Postgres database, I get this:

org.glassfish.jersey.server.model.ModelValidationException: 
Validation of the application resource model has failed during application initialization.
[[FATAL] No injection source found for a parameter of type public javax.ws.rs.core.Response com.example.PostResource.savePost(com.example.Post,javax.ws.rs.core.UriInfo) at index 0.; source='ResourceMethod{httpMethod=POST, consumedTypes=[application/json], producedTypes=[], suspended=false, suspendTimeout=0, suspendTimeoutUnit=MILLISECONDS, invocable=Invocable{handler=ClassBasedMethodHandler{handlerClass=class com.example.PostResource, handlerConstructors=[org.glassfish.jersey.server.model.HandlerConstructor@44c2e8a8]}, definitionMethod=public javax.ws.rs.core.Response com.example.PostResource.savePost(com.example.Post,javax.ws.rs.core.UriInfo), parameters=[Parameter [type=class com.example.Post, source=null, defaultValue=null], Parameter [type=interface javax.ws.rs.core.UriInfo, source=null, defaultValue=null]], responseType=class javax.ws.rs.core.Response}, nameBindings=[]}']

That seems to be a different problem entirely.

I will submit a pull request soon to fix the EntityManagerFactory initialization problem.

[ljnelson]

Good news; with hantsy/helidon-sandbox#1 and a resolution for #3009 your mp-jpa project works.

I'll submit a PR for #3009 soon.

I will also submit a PR against your sample code to work around this problem in the meantime (it should be an easy fix).

[ljnelson]

I've also posted hantsy/helidon-sandbox#2. If you apply hantsy/helidon-sandbox#2 and hantsy/helidon-sandbox#1, your project works (tested with (Helidon-supported) JDK 11).

[hantsy]

Thanks @ljnelson , finally got it working on Java 16.