Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JPA writes don't work when using ONLY named data sources since 3.13.0 #42314

Closed
krisztiankocsis opened this issue Aug 5, 2024 · 17 comments · Fixed by #42400
Closed

JPA writes don't work when using ONLY named data sources since 3.13.0 #42314

krisztiankocsis opened this issue Aug 5, 2024 · 17 comments · Fixed by #42400
Labels
area/persistence OBSOLETE, DO NOT USE kind/bug Something isn't working
Milestone

Comments

@krisztiankocsis
Copy link

krisztiankocsis commented Aug 5, 2024

Describe the bug

We upgrade Quarkus from 3.12.0 -> 3.13.0. We are using 3 named data sources / Hibernate ORM configuration - no default data source is configured. This was working till 3.13.0. DB reads still work, but as soon as we do any update agains a named DB, we get the following exception:

The default datasource has not been properly configured. See https://quarkus.io/guides/datasource#jdbc-datasource for information on how to do that.

Expected behavior

Both DB reads/writes work the same way as in the previous version, and not complaining about unconfigured default data source - we don't need such.

Actual behavior

It is throwing an exception about the missing default data source configuration.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

21

Quarkus version or git rev

3.13.0

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

@krisztiankocsis krisztiankocsis added the kind/bug Something isn't working label Aug 5, 2024
@krisztiankocsis
Copy link
Author

Downgrading back to 3.12.3, it starts working again as expected (updates going through without having such an exception).

@geoand
Copy link
Contributor

geoand commented Aug 5, 2024

Thanks for reporting.

I assume you mean 3.13 and not 1.13, correct?

@geoand geoand added area/persistence OBSOLETE, DO NOT USE and removed triage/needs-triage labels Aug 5, 2024
@quarkus-bot
Copy link

quarkus-bot bot commented Aug 5, 2024

/cc @DavideD (hibernate-reactive), @gavinking (hibernate-reactive), @gsmet (hibernate-orm), @mswatosh (db2), @yrodiere (hibernate-orm)

@krisztiankocsis
Copy link
Author

Thanks for reporting.

I assume you mean 3.13 and not 1.13, correct?

Yeap, its 3.13 (and 3.12 is working).

@krisztiankocsis krisztiankocsis changed the title JPA writes don't work when using ONLY named data sources since 1.13.0 JPA writes don't work when using ONLY named data sources since 3.13.0 Aug 5, 2024
@gsmet
Copy link
Member

gsmet commented Aug 8, 2024

@krisztiankocsis can you provide the full stacktrace?

@gsmet
Copy link
Member

gsmet commented Aug 8, 2024

Also it would help if you could assemble a small reproducer so that we could reproduce the issue easily.

@gsmet
Copy link
Member

gsmet commented Aug 8, 2024

/cc @marko-bekhta FYI

@krisztiankocsis
Copy link
Author

{ "timestamp": "2024-08-08T11:42:48.239339829+02:00", "sequence": 3211, "loggerName": "com.bmw.ipdm.cedec.simon.control.AbstractWorkerThread", "level": "ERROR", "message": "An unexpected error occurred in ZAK Transmission thread loop", "threadName": "ZAK Transmission", "threadId": 68, "mdc": {}, "ndc": "", "exception": { "refId": 1, "exceptionType": "java.lang.IllegalStateException", "message": "The default datasource has not been properly configured. See https://quarkus.io/guides/datasource#jdbc-datasource for information on how to do that.", "frames": [ { "class": "io.quarkus.hibernate.orm.panache.common.runtime.AbstractJpaOperations", "method": "getSession", "line": 74 }, { "class": "io.quarkus.hibernate.orm.panache.common.runtime.AbstractJpaOperations", "method": "executeUpdate", "line": 485 }, { "class": "io.quarkus.hibernate.orm.panache.common.runtime.AbstractJpaOperations", "method": "update", "line": 515 }, { "class": "com.bmw.ipdm.cedec.simon.entity.simon.SimonSimulationDataRecord", "method": "update" }, { "class": "com.bmw.ipdm.cedec.simon.control.SimulationDataStore", "method": "acquireForExecution", "line": 701 }, { "class": "com.bmw.ipdm.cedec.simon.control.SimulationDataStore_Subclass", "method": "acquireForExecution$$superforward" }, { "class": "com.bmw.ipdm.cedec.simon.control.SimulationDataStore_Subclass$$function$$1", "method": "apply" }, { "class": "io.quarkus.arc.impl.AroundInvokeInvocationContext", "method": "proceed", "line": 73 }, { "class": "io.quarkus.arc.impl.AroundInvokeInvocationContext", "method": "proceed", "line": 62 }, { "class": "io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorBase", "method": "invokeInCallerTx", "line": 335 }, { "class": "io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorRequired", "method": "doIntercept", "line": 40 }, { "class": "io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorBase", "method": "intercept", "line": 61 }, { "class": "io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorRequired", "method": "intercept", "line": 32 }, { "class": "io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorRequired_Bean", "method": "intercept" }, { "class": "io.quarkus.arc.impl.InterceptorInvocation", "method": "invoke", "line": 42 }, { "class": "io.quarkus.arc.impl.AroundInvokeInvocationContext", "method": "perform", "line": 30 }, { "class": "io.quarkus.arc.impl.InvocationContexts", "method": "performAroundInvoke", "line": 27 }, { "class": "com.bmw.ipdm.cedec.simon.control.SimulationDataStore_Subclass", "method": "acquireForExecution" }, { "class": "com.bmw.ipdm.cedec.simon.control.SimulationDataStore_ClientProxy", "method": "acquireForExecution" }, { "class": "com.bmw.ipdm.cedec.simon.control.zak.FutureSimulationFetcher", "method": "findAndAcquireOldestInitiatedNotDeadNotPreventedSimulation", "line": 85 }, { "class": "com.bmw.ipdm.cedec.simon.control.zak.FutureSimulationFetcher_Subclass", "method": "findAndAcquireOldestInitiatedNotDeadNotPreventedSimulation$$superforward" }, { "class": "com.bmw.ipdm.cedec.simon.control.zak.FutureSimulationFetcher_Subclass$$function$$1", "method": "apply" }, { "class": "io.quarkus.arc.impl.AroundInvokeInvocationContext", "method": "proceed", "line": 73 }, { "class": "io.quarkus.arc.impl.AroundInvokeInvocationContext", "method": "proceed", "line": 62 }, { "class": "io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorBase", "method": "invokeInOurTx", "line": 136 }, { "class": "io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorBase", "method": "invokeInOurTx", "line": 107 }, { "class": "io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorRequired", "method": "doIntercept", "line": 38 }, { "class": "io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorBase", "method": "intercept", "line": 61 }, { "class": "io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorRequired", "method": "intercept", "line": 32 }, { "class": "io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorRequired_Bean", "method": "intercept" }, { "class": "io.quarkus.arc.impl.InterceptorInvocation", "method": "invoke", "line": 42 }, { "class": "io.quarkus.arc.impl.AroundInvokeInvocationContext", "method": "perform", "line": 30 }, { "class": "io.quarkus.arc.impl.InvocationContexts", "method": "performAroundInvoke", "line": 27 }, { "class": "com.bmw.ipdm.cedec.simon.control.zak.FutureSimulationFetcher_Subclass", "method": "findAndAcquireOldestInitiatedNotDeadNotPreventedSimulation" }, { "class": "com.bmw.ipdm.cedec.simon.control.zak.FutureSimulationFetcher", "method": "getNextExecutableSimulation", "line": 61 }, { "class": "com.bmw.ipdm.cedec.simon.control.zak.SimulationTransmissionThread", "method": "runActionRepeatedly", "line": 45 }, { "class": "com.bmw.ipdm.cedec.simon.control.AbstractWorkerThread", "method": "run", "line": 64 } ] } }

Here is the stack trace.
Note that the code is called from a thread NOT managed by Quarkus!
However, this was working in 3.12.3.

DB updates comming from a Vert.X worker thread seem to work.

@gsmet

@krisztiankocsis
Copy link
Author

Maybe the issue is with the non-managed thread, and not the multiple data sources.

@krisztiankocsis
Copy link
Author

We have 3 special threads, so we need a solution to be able to keep them.

@marko-bekhta
Copy link
Contributor

I didn't see any obvious change in 3.13 to explain the different behaviour.. Is there any chance you can create a small reproducer @krisztiankocsis, as Guillaume was suggesting? That'll help us track down the reason for this change of behaviour. Thanks!

@gsmet
Copy link
Member

gsmet commented Aug 8, 2024

I think I found the culprit and this is embarrassing.

@gsmet
Copy link
Member

gsmet commented Aug 8, 2024

Should be fixed by #42400.

@krisztiankocsis
Copy link
Author

I checked the changes in the fix commit. That perfectly makes sense. Thanks for the quick fix @gsmet!

@gsmet
Copy link
Member

gsmet commented Aug 8, 2024

@marko-bekhta added some tests. I will merge once CI is green.

I think I will expedite a 3.13.2 once this is merged as it's rather annoying. Thanks for the report!