Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » DatabaseException is always logged to server.log(I want to test for a lock on a row, this works basically, but an exception is always logged with stacktrace and pollutes the server.log file.)
DatabaseException is always logged to server.log [message #1860098] Mon, 17 July 2023 18:13 Go to next message
Ulrich Cech is currently offline Ulrich CechFriend
Messages: 8
Registered: February 2018
Junior Member
Hi to all,

I have a problem with perhaps eclipselink, and I did not find any solution.

I will synchronize multiple cluster-node by database and try to use a row-lock:

        Map<String, Object> properties = new HashMap<>();
        properties.put("javax.persistence.lock.timeout", timeout);
        properties.put("jakarta.persistence.lock.timeout", timeout);
        final PlatformDatabaseLock lock = getEntityManager().find(PlatformDatabaseLock.class, processId, LockModeType.PESSIMISTIC_WRITE, properties);


This works, but if some execution hits the lock, there is an exception thrown, which is not catchable. It always is propagated to serverlog, so the whole serverlog is polluted with this exception and the corresponding stackstack, and searching for real errors is nearly impossible.

I tried with try/catch around the statement, around the method-call, around the call to the EJB... I tried it with an Interceptor... nothing worked.

I also set this parameter in persistence.xml, but this does not have any effect:
<property name="eclipselink.logging.exceptions" value="false" />


Can somebody tell me, how to check for a lock on a row of a table but without having to deal with exceptions?

The exception and the stacktrace are show here:

Local Exception Stack:
Exception [EclipseLink-4002] (Eclipse Persistence Services - 4.0.1.payara-p1.v202304041433): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: org.postgresql.util.PSQLException: ERROR: could not obtain lock on row in relation "_platform_database_lock"
Error Code: 0
Call: SELECT _id, created, last_update, platform_lock_until, version FROM _platform_database_lock WHERE (_id = ?) FOR UPDATE NOWAIT
bind => [EMAIL_NOTIFICATION_IMMEDIATELY]
Query: ReadObjectQuery(name="readPlatformDatabaseLock" referenceClass=PlatformDatabaseLock sql="SELECT _id, created, last_update, platform_lock_until, version FROM _platform_database_lock WHERE (_id = ?) FOR UPDATE NOWAIT")
at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:343)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.processExceptionForCommError(DatabaseAccessor.java:1805)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:694)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:569)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:2048)
at org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:311)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:280)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:266)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.selectOneRow(DatasourceCallQueryMechanism.java:813)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectOneRowFromTable(ExpressionQueryMechanism.java:2912)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectOneRow(ExpressionQueryMechanism.java:2865)
at org.eclipse.persistence.queries.ReadObjectQuery.executeObjectLevelReadQuery(ReadObjectQuery.java:563)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:1236)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:913)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1195)
at org.eclipse.persistence.queries.ReadObjectQuery.execute(ReadObjectQuery.java:448)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1283)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:3008)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1841)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1823)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1773)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.executeQuery(EntityManagerImpl.java:999)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.findInternal(EntityManagerImpl.java:941)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.find(EntityManagerImpl.java:817)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.find(EntityManagerWrapper.java:402)
at de.example.domainmodel.platform.persistence.PersistenceAware.getExclusiveLock(PersistenceAware.java:104)
at de.example.domain.business.notifications.email.PersonalMessageMailNotificationImmediatelyScheduler.execute(PersonalMessageMailNotificationImmediatelyScheduler.java:46)
at jdk.internal.reflect.GeneratedMethodAccessor290.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:588)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:408)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4835)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:653)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:834)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:603)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:145)
at jdk.internal.reflect.GeneratedMethodAccessor227.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:888)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:833)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:603)
at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
at org.jboss.weld.module.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at jdk.internal.reflect.GeneratedMethodAccessor200.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:888)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:833)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:375)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4807)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4795)
at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:4045)
at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1208)
at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:1937)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.postgresql.util.PSQLException: ERROR: could not obtain lock on row in relation "_platform_database_lock"
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2676)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2366)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:356)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:496)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:413)
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:190)
at org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:134)
at jdk.internal.reflect.GeneratedMethodAccessor193.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.postgresql.ds.PGPooledConnection$StatementHandler.invoke(PGPooledConnection.java:441)
at jdk.proxy74/jdk.proxy74.$Proxy655.executeQuery(Unknown Source)
at com.sun.gjc.spi.jdbc40.PreparedStatementWrapper40.executeQuery(PreparedStatementWrapper40.java:658)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeSelect(DatabaseAccessor.java:1026)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:662)
... 59 more


Thank you very much for every hint to come around this issue!
Re: DatabaseException is always logged to server.log [message #1860100 is a reply to message #1860098] Mon, 17 July 2023 19:17 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris DelahuntFriend
Messages: 54
Registered: December 2021
Member
What you are showing looks like just EclipseLink logging of the DB exception when it gets it. This exception will get wrapped in either LockTimeoutException or PessimisticLockException and be thrown by the find call, which you are expected to deal with.

If this logging is the issue, check out https://wiki.eclipse.org/EclipseLink/Examples/JPA/Logging as it is likely logging settings are being controlled through your server in a server managed persistence unit.
Re: DatabaseException is always logged to server.log [message #1860167 is a reply to message #1860100] Thu, 20 July 2023 15:00 Go to previous messageGo to next message
Ulrich Cech is currently offline Ulrich CechFriend
Messages: 8
Registered: February 2018
Junior Member
Hi Chris,
thank you very much for your comment.

The point here is the following: I could log the eclipselink exceptions into a separate file, but generally, I definitely WANT the exceptions to be logged in one place, so the overall-logging configuration fits quite well.

But what I find strange here is the thing, that this exception could not be catched (or more precisely, I COULD be catched, but it is "magically" logged to the main server.log).
It seems like this exception, even if catched, is handled like an uncatched exception, which is afterwards printed to server-log.
I have this settings in my persistsnce.xml file.
<property name="eclipselink.logging.exceptions" value="false" />

but it has absolutely no effect.

Is there perhaps another "pattern" to check for locks in a database with JPA? Because I think, this will be a common problem not only for me, that every hit against a lock pollutes the server log-file.

Thanks again for any hint/input/tip ;-)

[Updated on: Thu, 20 July 2023 15:00]

Report message to a moderator

Re: DatabaseException is always logged to server.log [message #1860198 is a reply to message #1860167] Fri, 21 July 2023 14:18 Go to previous message
Chris Delahunt is currently offline Chris DelahuntFriend
Messages: 54
Registered: December 2021
Member
Sorry I wasn't clear.

This isn't an issue with how locks are checked in the DB - it is entirely an issue with your logging setup in your container.

<property name="eclipselink.logging.exceptions" value="false" /> in a persistence.xml is an EclipseLink logging setting. If you have configured EclipseLink to use a server logger, this setting doesn't apply - it and other eclipselink log settings ONLY apply to EclipseLink loggers (DefaultLogger).

Glassfish injects its own classes and logger into persistence units, much like it tries to handle DDL generation on its own. If you want to control logging, these will be glassfish logging options and settings. Happy to take a look if you want to post all your settings, but I'm not overly familiar with glassfish as I haven't had the opportunity to use it in a number of years.

[Updated on: Fri, 21 July 2023 14:19]

Report message to a moderator

Previous Topic:Memory comsumption with eclipselink (2.7)
Next Topic:Eclipselink throwing error while running junit
Goto Forum:
  


Current Time: Sat Apr 27 18:46:55 GMT 2024

Powered by FUDForum. Page generated in 0.02930 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top