Getting Exception [EclipseLink-4002] on EclipseLink 2.6.0 or higher while same code working fine with EclipseLink 2.5.2

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Getting Exception [EclipseLink-4002] on EclipseLink 2.6.0 or higher while same code working fine with EclipseLink 2.5.2

pradeepagrawal8184
[EL Info]: server: 2016-04-19 05:26:55.251--ServerSession(283635624)--Detected server platform: org.eclipse.persistence.platform.server.NoServerPlatform.
[EL Info]: server: 2016-04-19 05:26:57.716--ServerSession(1706130424)--Detected server platform: org.eclipse.persistence.platform.server.NoServerPlatform.
[EL Warning]: 2016-04-19 05:27:14.446--ClientSession(1455873973)--Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.6.0.v20150309-bf26070): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: com.microsoft.sqlserver.jdbc.SQLServerException: Invalid object name 'x_service_config_def_SEQ'.
Error Code: 208
Call: SELECT NEXT VALUE FOR x_service_config_def_SEQ
Query: ValueReadQuery(sql="SELECT NEXT VALUE FOR x_service_config_def_SEQ")
[EL Warning]: transaction: 2016-04-19 05:27:14.533--UnitOfWork(1200773678)--The class RepeatableWriteUnitOfWork is already flushing. The query will be executed without further changes being written to the database.  If the query is conditional upon changed data the changes may not be reflected in the results.  Users should issue a flush() call upon completion of the dependent changes and prior to this flush() to ensure correct results.
[EL Warning]: transaction: 2016-04-19 05:27:14.818--UnitOfWork(1200773678)--The class RepeatableWriteUnitOfWork is already flushing. The query will be executed without further changes being written to the database.  If the query is conditional upon changed data the changes may not be reflected in the results.  Users should issue a flush() call upon completion of the dependent changes and prior to this flush() to ensure correct results.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting Exception [EclipseLink-4002] on EclipseLink 2.6.0 or higher while same code working fine with EclipseLink 2.5.2

christopher delahunt
Looks like you are getting this changed behavior as a result of the fix
for https://bugs.eclipse.org/bugs/show_bug.cgi?id=447549 which added
sequence support to the SQLServerPlatform database platform. The new
code does a database version check to see if it is >=11 to enable
sequencing for it.

I suspect your app was misconfigured originally, possibly to use a
Sequence object, which just defaulted to table sequencing as it wasn't
supported by the platform in 2.5.2.
Changing the configuration to something other then Sequence should fix
the issue, or you can subclass the database platform class to behave as
it did in 2.5.2.

Best Regards,
Chris

On 21/04/2016 12:29 AM, pradeepagrawal8184 wrote:

> [EL Info]: server: 2016-04-19
> 05:26:55.251--ServerSession(283635624)--Detected server platform:
> org.eclipse.persistence.platform.server.NoServerPlatform.
> [EL Info]: server: 2016-04-19
> 05:26:57.716--ServerSession(1706130424)--Detected server platform:
> org.eclipse.persistence.platform.server.NoServerPlatform.
> [EL Warning]: 2016-04-19 05:27:14.446--ClientSession(1455873973)--Exception
> [EclipseLink-4002] (Eclipse Persistence Services - 2.6.0.v20150309-bf26070):
> org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception: com.microsoft.sqlserver.jdbc.SQLServerException: Invalid
> object name 'x_service_config_def_SEQ'.
> Error Code: 208
> Call: SELECT NEXT VALUE FOR x_service_config_def_SEQ
> Query: ValueReadQuery(sql="SELECT NEXT VALUE FOR x_service_config_def_SEQ")
> [EL Warning]: transaction: 2016-04-19
> 05:27:14.533--UnitOfWork(1200773678)--The class RepeatableWriteUnitOfWork is
> already flushing. The query will be executed without further changes being
> written to the database.  If the query is conditional upon changed data the
> changes may not be reflected in the results.  Users should issue a flush()
> call upon completion of the dependent changes and prior to this flush() to
> ensure correct results.
> [EL Warning]: transaction: 2016-04-19
> 05:27:14.818--UnitOfWork(1200773678)--The class RepeatableWriteUnitOfWork is
> already flushing. The query will be executed without further changes being
> written to the database.  If the query is conditional upon changed data the
> changes may not be reflected in the results.  Users should issue a flush()
> call upon completion of the dependent changes and prior to this flush() to
> ensure correct results.
>
>
>
> --
> View this message in context: http://eclipse.1072660.n5.nabble.com/Getting-Exception-EclipseLink-4002-on-EclipseLink-2-6-0-or-higher-while-same-code-working-fine-with-2-tp181386.html
> Sent from the EclipseLink - Users mailing list archive at Nabble.com.
> _______________________________________________
> eclipselink-users mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users

_______________________________________________
eclipselink-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting Exception [EclipseLink-4002] on EclipseLink 2.6.0 or higher while same code working fine with EclipseLink 2.5.2

pradeepagrawal8184
Hi,

Thanks for replying; I am not sure whether configuration change can be done as we have support for MySQL/Oracle/Postgres/SqlAnywhere and MS SQL Server.

if you refer line 39-41 of the class : then probably you can figure out what do we do. Based on database flavor EclipseLink 2.5.2 jar automatically detect whether to use sequence or auto number/identity etc.

You said : "you can subclass the database platform class to behave as it did in 2.5.2."

Don't know how it can be implemented in our context. Will explore more on this; if you have reference of mentioned implementation would you please refer that to me.

Loading...