eclipse-ee4j/eclipselink

Eclipselink project

eclipselink's Issues

Bug #532160: eclipselink OraclePlatform QueryHint FIRST_ROWS does not use max parameter

Linking to BZ #532160

Bug 536319: Sunset the Oracle v8-v10 platform classes

Linking to BZ #536319

Bug #534001: Update deprecated BREE with ee.capability

Linking to BZ #534001

Support Gradle incremental annotation processing

Linked to BZ #535985

This would greatly reduce build time for projects using Gradle.

org.eclipse.persistence.asm is not building OK on 2.6.5 tag

org.eclipse.persistence.asm is not building right on 2.6.5 tag since 2.6.x branches miss the commit:

mertcaliskan:eclipselink mertcaliskan$ git tag --contains 1775741f577b9af6f55b3d425e08e7d4842fc615
2.7.0
2.7.0-RC1
2.7.0-RC2
2.7.0-RC3
2.7.1
2.7.1-RC1
2.7.2
2.7.2-RC1
2.7.2-RC2

Cascading detach does not work at uninstantiated indirection objects

AS-IS:

When you detach an entity which has a lazy relationship to uninstantiated entity or entities, detach behaviour is not cascading on fetched object(s) and its state will be MANAGED.

SHOULD-BE:

Add and set a flag in a DatabaseValueHolder instance that after instantiation the fetched object(s) should be unregistered from the session. After that its state will be DETACHED.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=541391

Eclipselink MetaDataProject uses the wrong field in processStage2

While doing some investigation into migrating from Eclipselink 2.6.5 to Eclipselink 2.7.3 we found that the JPA canonical metamodel functionality is broken. Effectively this means that all queries that want to leverage the JPA canonical model result in NPEs. Debugging the issues shows that there is a change made in the processStage2 method of the MetaDataProject. Initially that method started with:

        for (MappedSuperclassAccessor msAccessor : m_metamodelMappedSuperclasses.values()) {
            if (! msAccessor.isProcessed()) {
                msAccessor.processMetamodelDescriptor();
            }
        }

Where as of 2.7.3 this starts with:

        for (MappedSuperclassAccessor msAccessor : getMappedSuperclasses()) {
            if (! msAccessor.isProcessed()) {
                msAccessor.processMetamodelDescriptor();
            }
        }

So instead of using the metamodelMappedSuperclasses it tries to go to work on the mappedSuperclasseAccessors

Bug 536853: MapsID processing sets up to fail validation with entities with identities using multiple nested embeddable with a common accessor name

https://bugs.eclipse.org/bugs/show_bug.cgi?id=536853

Bug 543846: Stored Procedure named parameter with DB2/Z doesn't work

Linking to BZ #543846

JPQL query can not be parsed in Turkish locale

if the query contains LIKE or IS NULL condition, it can not be executed in Turkish locale.
Project with test: com.company.jpa.QueryTest
test-jpa.zip

Error:

Exception Description: Syntax error parsing [select u from sec$User u where u.loginLowerCase like :login]. 
[31, 59] The expression is not a valid conditional expression.
	at org.eclipse.persistence.internal.jpa.jpql.HermesParser.buildException(HermesParser.java:155)
	at org.eclipse.persistence.internal.jpa.jpql.HermesParser.validate(HermesParser.java:334)
	at org.eclipse.persistence.internal.jpa.jpql.HermesParser.populateQueryImp(HermesParser.java:278)
	at org.eclipse.persistence.internal.jpa.jpql.HermesParser.buildQuery(HermesParser.java:163)
	at org.eclipse.persistence.internal.jpa.EJBQueryImpl.buildEJBQLDatabaseQuery(EJBQueryImpl.java:142)
	at org.eclipse.persistence.internal.jpa.EJBQueryImpl.buildEJBQLDatabaseQuery(EJBQueryImpl.java:116)
	at org.eclipse.persistence.internal.jpa.EJBQueryImpl.<init>(EJBQueryImpl.java:102)
	at org.eclipse.persistence.internal.jpa.EJBQueryImpl.<init>(EJBQueryImpl.java:86)
	at org.eclipse.persistence.internal.jpa.EntityManagerImpl.createQuery(EntityManagerImpl.java:1614)
	... 27 more

This repository is not referenced from anywhere and hard to find

1. Searching in Google for Eclipselink repository returns https://github.com/eclipse/eclipselink.runtime as a first result. The repository seems legit on the first glance, until you check date of the last commit. There is no any other indication that is is not uses anymore or link to this repository.
2. I was unable to find any references to this repository on eclipse.org
3. There is a bug tracker on eclipse.org that allows opening new bugs for Eclipselink, but it seems that nobody check them anymore. There is no clear indication for it, but I did not notice much activity there.

The bottom line is that although this repository is public, many potential contributors may miss it and create pull requests on https://github.com/eclipse/eclipselink.runtime or open bugs on https://bugs.eclipse.org/bugs/describecomponents.cgi?product=EclipseLink
😕

Precision of Oracle timestamp query is too low

In org.eclipse.persistence.core/src/org/eclipse/persistence/platform/database/OraclePlatform.java, getTimestampQuery() returns a query like "SELECT SYSDATE FROM DUAL".
SYSDATE has a precision of 1 second which is clearly too low for e.g. optimistic locking. It should be replaced by LOCALTIMESTAMP for the best available precision.
Note: SYSTIMESTAMP cannot be used because it includes the timezone and therefore cannot be converted to java.sql.Timestamp.

createNativeQuery(String,Class) is loses the template parameter

eclipselink/jpa/org.eclipse.persistence.jpa/src/org/eclipse/persistence/internal/jpa/EntityManagerImpl.java

Lines 1307 to 1308 in ac5913f

	@Override
	public Query createNativeQuery(String sqlString, Class resultType) {

Why is it necessary Query return type? Why not TypedQuery is a return type?

Recursive annotations triggers a StackOverflowError

When an annotation class annotated with itself gets scanned by EclipseLink (<exclude-unlisted-classes>false</exclude-unlisted-classes>), it enters into a recursive loop which triggers a StackOverflowError where org.eclipse.persistence.internal.jpa.metadata.accessors.objects.MetadataAnnotatedElement.getAnnotation(MetadataAnnotatedElement.java:215) calls itself.

@Self
public @interface Self {}

It happens in payara-micro 5 (EclipseLink 2.7.1.qualifier), but it didn't happen in payara-micro 4. A sample WAR can be found in payara/Payara#2608.

Bug 537795: CASE THEN and ELSE scalar expression Constants should not be casted to CASE operand type

Issue for https://bugs.eclipse.org/bugs/show_bug.cgi?id=537795

Given a query:

TypedQuery query = em.createQuery(""
+ "SELECT t FROM EntityTbl01 t "
+ "WHERE t.itemString1 = ( "
+ "CASE "
+ "WHEN t.itemInteger1 = 1000 THEN '047010' "
+ "WHEN t.itemInteger1 = 100 THEN '023010' "
+ "ELSE '033020' "
+ "END )", EntityTbl01.class);

the query processing involved with converting the CASE scalar_expressions to statement parameters typecasts the constant value to the case_operation type. For THEN/ELSE scalar_expressions of an incompatible type this can lead to a failure.

Bug #533022: JSE test bucket fails to compile

Linking to BZ #533022

Migrate project to maven

Hi everyone!

Is there any plan to migrate to maven structured project?
Many Jakarta EE projects are maven based or have been migrated such as jsonp, mojarra and so on,
It's more convenient and clear to organize the whole complex project and easier to set up project in a new environment.

I would like to help if we can add it to our roadmap.
Thanks!

Integrate to GlassFish

• Integrate to Eclipse GlassFish.
• Pass all CTS/TCK tests.

Failed to load Orbit S20180302171354

Getting the following exception when building 2.7 & master branches:

[java] [ERROR] Internal error: java.lang.RuntimeException: Failed to load p2 repository with ID 'Orbit' from location http://download.eclipse.org/tools/orbit/downloads/drops/S20180302171354/repository: Unable to read repository at http://download.eclipse.org/tools/orbit/downloads/drops/S20180302171354/repository. Artifact not found: http://download.eclipse.org/tools/orbit/downloads/drops2/S20180302171354/repository/content.xml.xz. -> [Help 1]
[java] org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: Failed to load p2 repository with ID 'Orbit' from location http://download.eclipse.org/tools/orbit/downloads/drops/S20180302171354/repository
[java]     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168)
[java]     at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
[java]     at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[java]     at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)

It seems http://download.eclipse.org/tools/orbit/downloads/drops/S20180302171354 was deleted. Not sure why, but I can update to use R20180606145124 to get the builds running again.

org.eclipse.persistence.jpa depends on javax.json-api but doesn't use it

Hi,

I am migrating a Maven project from OpenJPA to EclipseLink JPA and I saw something which looked weird to me, so I thought I should report it. I added the following dependencies to my project's pom.xml:

            <dependency>
                <groupId>org.eclipse.persistence</groupId>
                <artifactId>org.eclipse.persistence.jpa</artifactId>
                <version>2.7.3</version>
            </dependency>
            <dependency>
                <groupId>org.eclipse.persistence</groupId>
                <artifactId>org.eclipse.persistence.extension</artifactId>
                <version>2.7.3</version>
            </dependency>

Unfortunately, due to my company's policy, I had to document all new dependencies (including transitive ones), so I went through them one by one. I saw that the org.eclipse.persistence.jpa artifact has a compile dependency to javax.json-api and I did a quick search through the code, but I couldn't find any usage of the javax.json package. I also tried excluding it and nothing broke. Is this dependency really necessary then? Removing it might save some time for other people in my situation.

Bug 536730: NPE on 2.6 when running with Java 11

Linking to BZ #536730

UnitOfWork throws NPE on calling commitAndResumeOnFailure()

Hello all,

We are doing migration from Toplink 10.1.3 to Eclipselink (native api) 2.7.2 with Java 8 for a web application.

In some scenarios when commitAndResumeOnFailure() is called on unit of work the below exception is thrown:

java.lang.NullPointerException
Message: null
-----
org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.insertObject(DatasourceCallQueryMechanism.java:432)
org.eclipse.persistence.internal.queries.StatementQueryMechanism.insertObject(StatementQueryMechanism.java:165)
org.eclipse.persistence.internal.queries.StatementQueryMechanism.insertObject(StatementQueryMechanism.java:180)
org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.insertObjectForWrite(DatabaseQueryMechanism.java:502)
org.eclipse.persistence.queries.InsertObjectQuery.executeCommit(InsertObjectQuery.java:80)
org.eclipse.persistence.queries.InsertObjectQuery.executeCommitWithChangeSet(InsertObjectQuery.java:90)
org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.executeWriteWithChangeSet(DatabaseQueryMechanism.java:314)
org.eclipse.persistence.queries.WriteObjectQuery.executeDatabaseQuery(WriteObjectQuery.java:58)
org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:911)
org.eclipse.persistence.queries.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:810)
org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:108)
org.eclipse.persistence.queries.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:85)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2979)
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1892)
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1874)
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1824)
org.eclipse.persistence.internal.sessions.CommitManager.commitNewObjectsForClassWithChangeSet(CommitManager.java:227)
org.eclipse.persistence.internal.sessions.CommitManager.commitAllObjectsForClassWithChangeSet(CommitManager.java:194)
org.eclipse.persistence.internal.sessions.CommitManager.commitAllObjectsWithChangeSet(CommitManager.java:139)
org.eclipse.persistence.internal.sessions.AbstractSession.writeAllObjectsWithChangeSet(AbstractSession.java:4384)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1491)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1581)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitRootUnitOfWork(UnitOfWorkImpl.java:1401)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitAndResume(UnitOfWorkImpl.java:1218)
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitAndResumeOnFailure(UnitOfWorkImpl.java:1297)

On debugging eclipselink library code, within insertObject() of DatasourceCallQueryMechanism.java, the accessor appears null and so the NPE.

eclipselink/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/queries/DatasourceCallQueryMechanism.java

Lines 432 to 445 in 3668d1a

	// Bug 3110860: RETURNINGPOLICY-OBTAINED PK CAUSES LOB TO BE INSERTED INCORRECTLY
	// The deferred locator SELECT calls should be generated and executed after ReturningPolicy
	// merges PK obtained from the db into the object held by the query.
	//
	//Oracle thin driver handles LOB differently. During the insert, empty lob would be
	//insert first, and then the LOb locator is retrieved and LOB data are written through
	//the locator.
	//
	// Bug 2804663 - LOBValueWriter is no longer a singleton, so we execute any deferred
	// select calls through the DatabaseAccessor which holds the writer instance
	AbstractSession executionSession = this.query.getExecutionSession();
	for (Accessor accessor : executionSession.getAccessors()) {
	accessor.flushSelectCalls(executionSession);
	}

The unitOfWork is property in bookingDataVO which is set in one of the Java classes, passed as parameter through different layers to different methods to register domain objects within it until it reaches a service method wherein commitAndResumeOnFailure() is called and it fails.

Is it a good practice to pass UnitOfWork across methods?
Could someone please provide more insight on this issue?

Also let me know if you need more information.

Thanks.

JDK 11 for Eclipselink

Hi,
Do you have any plans to support JDK 11?

Bug #391279: Provide support for unidirectional OneToMany with nullable=false

Linking to BZ #391279

Incorrect timestamp Format with @Temporal(TemporalType.TIMESTAMP)

https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408

Could you try to fix it in the next bugfix release 2.7.2?

Bug #534515: Incorrect return type set for CASE functions

Linking to BZ #534515

Bug #531062: Derby tests fail

BZ #531062 test fails on Derby

POSTGRESQL BIT(1) MAP TO BOOLEAN

When you map a table containing a bit(1) field in postgresql, eclipselink map it to a boolean field, when you retrieve the information from the database the information is obtained withoud problems but when you try to update or insert postgresql doen't accept true or false value for this field instead accept B'1' or B'0', if you try to use converter then the same stuff happed due to the type of parameter set for eclipselink to the query is boolean so it doenst accept data like string or other type.

Make ValueHolderInterface api generic

Bug #537360: Update to ASM 6.2 to support JDK 11

Linking to BZ #537360

Bug #540929: Persistence Property 'eclipselink.jdbc.sql-cast' doesn't apply

Linking to BZ #540929

MOXy JSON: marshalling decimals as strings

We have an old project that uses MOXy to convert between XML and JSON representations of some data. The classes themselves are generated from an XSD schema using XJC. A few days ago we stumbled upon a problem, the root of which was that the large xsd:decimal/BigDecimal values were marshalled as JSON numbers. The spec allows it, however not all JSON libraries support this. In this particular case, JavaScript's JSON.parse attempted to convert the value to a JS number, losing precision in the process.

The easiest solution in my case would be to marshal BigDecimals as JSON strings. However a custom XmlAdapter<String, BigDecimal> did not work off the bat - the values were still marshalled as JSON numbers. Further investigation shows that using @XmlSchemaType("decimal") for the field in question makes MOXy inject the marshalled string as a raw JSON value - that is, not quoted or checked - which can lead to invalid JSON!

It seems that there are two ways to marshal decimals as strings:

1. Remove the type metadata from the field (but only for JSON marshalling!). This requires maintaining conflicting metadata (probably using this - I haven't dug deep into it yet) for XML end JSON marshalling.
2. Abuse the weird XmlAdapter behavior so that it returns a quoted string. This XmlAdapter should only be used for marshalling to JSON. This also requires a conflicting metadata.

Both ways feel like hacks to me. Is there a better way to control the type of the resulting JSON value? At least something that can coexist with XML marshalling without me maintaining metadata overrides?

Here's an SSCCE.

Bug 533272 - JPA NamedStoredProcedure call getOutputParameterValue with parameter name cause exception

Linked to BZ #533272

Bug 536093: ArchiveFactoryImpl.isJarInputStream() requires doPriv block

Linking to BZ #536093

Bug #533148: Add new persistence property to turn off SQL deferral

Linking to BZ #533148

Add support for mulitple constructor result expressions

Add support to EclipseLink for multiple CriteriaBuilder CompoundSelection objects using constructor results and embedded constructors.

Test:

@BeforeClass
public static void populate() {
    EntityManager em = emf.createEntityManager();
		
    em.getTransaction().begin();
		
    L2 l2 = new L2(1, "L2-1");
    L2 l2_2 = new L2(2, "L2-1");
		
    L1 l1 = new L1(1, "L1-1", l2);
    L1 l1_2 = new L1(2, "L1-2", l2_2);
		
    em.persist(l2);
    em.persist(l2_2);
    em.persist(l1);
    em.persist(l1_2);
		
    em.getTransaction().commit();
    em.clear();
}

@Test
public void testCriteriaCompoundSelectionModel() {
    EntityManager em = emf.createEntityManager();

    final CriteriaBuilder builder = em.getCriteriaBuilder();
    final CriteriaQuery<L1Model> query = builder.createQuery(L1Model.class);
    final Root<L1> root = query.from(L1.class);
    final Join<L1, L2> l1ToL2 = root.join(L1_.l2);
    final CompoundSelection<L2Model> selection_l2 = builder.construct(L2Model.class, l1ToL2.get(L2_.id), l1ToL2.get(L2_.name));
    final CompoundSelection<L1Model> selection = builder.construct(L1Model.class, root.get(L1_.id), root.get(L1_.name), selection_l2);
    query.select(selection);

    TypedQuery<L1Model> q = em.createQuery(query);
    List<L1Model> l1List = q.getResultList();
    System.out.println("=== results ===");
    if (l1List != null && !l1List.isEmpty()) {
        for (L1Model l1m : l1List) {
            System.out.println(l1m.toString());
            Assert.assertNotNull(l1m.getL2());
        }
    }
    em.close();
}

Output:

=== results ===
L1Model [id=1, name=L1-1, l2=null]
L1Model [id=2, name=L1-2, l2=null]

eclipselink 2.7.3 compiled in java 8 but may need java 9

Hello,

Just noticed that eclipselink now pull javax.json-api 1.1.2 which is compiled in java 9.

When running a webapp with eclipselink 2.7.3 on jetty (9.2.25) with Java 8 we have this exception :

java.lang.RuntimeException: Error scanning entry module-info.class from jar file:/home/alexandre/.m2/repository/javax/json/javax.json-api/1.1.2/javax.json-api-1.1.2.jar
    at org.eclipse.jetty.annotations.AnnotationParser.parseJar (AnnotationParser.java:913)
    at org.eclipse.jetty.annotations.AnnotationParser.parse (AnnotationParser.java:831)
    at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call (AnnotationConfiguration.java:164)
    at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run (AnnotationConfiguration.java:549)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob (QueuedThreadPool.java:635)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run (QueuedThreadPool.java:555)
    at java.lang.Thread.run (Thread.java:748)
Caused by: java.lang.IllegalArgumentException
    at org.objectweb.asm.ClassReader.<init> (Unknown Source)
    at org.objectweb.asm.ClassReader.<init> (Unknown Source)
    at org.objectweb.asm.ClassReader.<init> (Unknown Source)
    at org.eclipse.jetty.annotations.AnnotationParser.scanClass (AnnotationParser.java:973)
    at org.eclipse.jetty.annotations.AnnotationParser.parseJarEntry (AnnotationParser.java:956)
    at org.eclipse.jetty.annotations.AnnotationParser.parseJar (AnnotationParser.java:909)
    at org.eclipse.jetty.annotations.AnnotationParser.parse (AnnotationParser.java:831)
    at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call (AnnotationConfiguration.java:164)
    at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run (AnnotationConfiguration.java:549)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob (QueuedThreadPool.java:635)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run (QueuedThreadPool.java:555)
    at java.lang.Thread.run (Thread.java:748)

May be the doc should be updated for users to know that java 9 could be a requirement for eclipselink 2.7.3 ?

We'll stick with eclipselink 2.7.2 and switch when we'll be ready for java 9+

Sincerely,

Bug with bulk update processing involving version field update parameter

The JPA 2.1 Specification states:

4.10 Bulk Update and Delete Operations
...
Bulk update maps directly to a database update operation, bypassing optimistic locking checks. Portable applications must manually update the value of the version column, if desired, and/or manually validate the value of the version column.

However, there is a problem with this when attempting to execute such a bulk update in Eclipselink. In certain scenarios, an UPDATE block that targets the version field is ignored, and instead replaces the Parameter with a Constant (generated at the time the query is generated, which gets cached and fouls up successive executions of the same query once it gets into the query cache, too.) When this happens, the parameter passed into the query is ignored.

Consider the following entity:

@Entity
public class TemporalVersionedEntity {
	@Id private long id;
	@Version private java.sql.Timestamp updatetimestamp;
...
}

and the following execution logic:

private final static String qStr1 = "UPDATE TemporalVersionedEntity  SET updatetimestamp = ?3 " +
     "WHERE id = ?1 AND updatetimestamp = ?2";
em.getTransaction().begin();
final Query q = em.createQuery(qStr1);
q.setParameter(1, theId);
q.setParameter(2, theOldTimestamp);
q.setParameter(3, new java.sql.Timestamp(System.currentTimeMillis());
final int count = q.executeUpdate();

However, when you run the query, you don't get the time put into parameter #3, you get a database time generated by Eclipselink when first processing the Query (in this case, the time returned from the database). Here's an example output from my unit test (which the above example is based on):

Running testTemporalVersionField1 ...
Bulk Update Parameter 3 = **2018-05-10 14:16:33.533**
[EL Fine]: sql: 2018-05-10 14:16:34.035--ClientSession(831654622)--Connection(319558327)--Thread(Thread[main,5,main])--UPDATE TEMPORALVERSIONEDENTITY SET UPDATETIMESTAMP = ? WHERE ((ID = ?) AND (UPDATETIMESTAMP = ?))
	bind => [**2018-05-10 14:16:33.02**, 1, 2018-05-10 14:16:32.365]

As you can see, the value that is actually sent to the database is not only the value not specified by the parameter, but from a time moments before parameter #3 was generated (using DerbyDB on the same machine, so system clock is the same.)

The crazy thing that confounded me before I figured out what was going on was if I changed the version field name from "updatetimestamp" to plain old "version", the test started working! This was particularly confounding since a @Version field can be named anything. However, it turned out to be an issue with iterating through the order of entries in a HashMap, and the keys happened to evaluate in a consistent order between running against both entities. Here is the affected code within org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.prepareUpdateAll():

    public void prepareUpdateAll() {
        ExpressionBuilder builder = ((UpdateAllQuery)getQuery()).getExpressionBuilder();
        HashMap updateClauses = ((UpdateAllQuery)getQuery()).getUpdateClauses();

        boolean updateClausesHasBeenCloned = false;
        // Add a statement to update the optimistic locking field if their is one.
        OptimisticLockingPolicy policy = getDescriptor().getOptimisticLockingPolicy();
        if (policy != null) {
            if(policy.getWriteLockField() != null) {
                Expression writeLock = builder.getField(policy.getWriteLockField());
                Expression writeLockUpdateExpression = policy.getWriteLockUpdateExpression(builder, getQuery().getSession());
                if (writeLockUpdateExpression != null) {
                    // clone it to keep user's original data intact
                    updateClauses = (HashMap)updateClauses.clone();
                    updateClausesHasBeenCloned = true;
                    updateClauses.put(writeLock, writeLockUpdateExpression);
                }
            }
        }
...
        Iterator it = updateClauses.entrySet().iterator();
        while(it.hasNext()) {
            Map.Entry entry = (Map.Entry)it.next();

            Object fieldObject = entry.getKey();
...

Here, we get the OptimisticLockingPolicy (OLP) for the entity in question, and since the entity has a @Version field it returns an instance of TimestampLockingPolicy. It enters the nested if-block, producing a FieldExpression value for Expression writeLock and a ConstantExpression value for Expression writeLockUpdateExpression. These are then added to the updateClauses hashMap (whether they're needed or not), which already includes the QueryKeyExpression/ParameterExpression for Parameter 3 (the parameter updating the version column in the update clause.)

Here's a snapshot of the updateClauses HashMap after the insertion (for the failing scenario):

updateClauses	HashMap<K,V>  (id=125)	
	[0]	HashMap$Node<K,V>  (id=128)	
		key	QueryKeyExpression  (id=118) = Query Key updatetimestamp
		value	ParameterExpression  (id=119) = Parameter 3
	[1]	HashMap$Node<K,V>  (id=130)	
		key	FieldExpression  (id=95)  = Field TEMPORALVERSIONEDENTITY.UPDATETIMESTAMP
		value	ConstantExpression  (id=99) = Constant 2018-05-10 14:30:02.07	

Which is later iterated through starting on line 1871. The order actually matters in whether the update works or not -- in the failing case the QueryExpression is iterated first (and lost when iterating the second entry in the map) In the "passing case" where the version column is "version" the FieldExpression actually is inserted before the existing entry instead of after, allowing it to work as expected by happenstance.

Bug #500753 - Concurrency failure when persisting across multiple threads

Linking to BZ #500753

Bug #341074: CriteriaBuilder coalesce java.lang.ClassCastException when using literals

Linking to BZ 341074

Start a Release Review

Passing Release Review is a required step before making a first public release. Deadline for passing the review is Nov 30th, 2018. Release review takes some time to complete, so it makes sense initiating it as soon as possible.

• Start Release Review
• Update Release Review Tracker

Additional information:

• How to submit a release review
• Eclipse Handbook

Setting `jdbc.cache-statements` to `true` causes prepared statement get released

Version

2.7.1 (the latest version I can find in the maven repository)

Configuration

• data source provider: HikariCP
• set eclipselink.jdbc.cache-statements to true

How this is uncovered

I am trying to understand why actframework's performance on TFB single query testing degrade seriously from 61ff99e2-2392-4d7a-b6af-a5f081c5e004 to f62c00e2-070f-4636-90a3-1ba2687271a4

I choose the act-eclipselink-mysql configuration to start my work. During the course of troubleshooting, I tried to put eclipselink.jdbc.cache-statements=true in the project and found it drastically slow down the system throughput.

Details

When eclipselink.jdbc.cache-statements set to true, it will set the DatabasePlatform's shouldCacheAllStatements to true through EntityManagerSetupImpl.updateCacheStatementSettings(Map) as shown below:

With DatabasePlatform.shouldCacheAllStatements set to true, the DatabaseAccessor's releaseStatements(...) method will try to getStatementCache():

As we are using HikariCP as external datasource pool, it obviously shall delegate the statement cache to HikariCP, instead of creating statement cache inside EclipseLink. And the consequences is when it call to DatabaseAccessor.clearStatementCache(AbstractSession), it will get the statement from the internal cache and close it:

Unfortunately the DatabaseAccessor.clearStatementCache(AbstractSession) statement which is invoked by DatabaseAccessor.closeConnection() method, will get called twice in a single transaction:

1. Call through DatabaseAccessor.decrementCallCount():
   

2. Call through DatabaseAccessor.releaseStatement():
   

The first call will call cause HikariCP to recycle the statement and the second call will cause HikariCP to release the statement. Thus the next transaction will cause a full prepared statement construction inside mysql jdbc connector, which cause performance downgrade. Set eclipselink.jdbc.cache-statements to false will get significant performance gain.

Bug 544160: CriteriaBuilder treat incorrectly sets the managedType

Linking to BZ #544160

2.6.5 release breaks JDK7 compatibility

commit a49fe7b upgrades asm_5.0.1.v201405080102 to asm_6.0.0.v201702131300. This commit also resides within 2.6.5 release which breaks JDK7 compatibility since asm_6.0.0.v201702131300 requires JDK8 at least

javax.persistence still part of jar

Environment

Platform: OpenJDK 10.0.2
Operating system: macOS High Sierra
eclipselink version: 2.7.3

Issue

When starting my application, I get the following error:

java.lang.SecurityException: class "javax.persistence.PersistenceUtil"'s signer information does not match signer information of other classes in the same package

The class that is mentioned here is part of the eclipselink jar, which is not signed.

According to this PR , the javax.persistence package was removed from the eclipselink jar.
If I extract the jar, I can see the package being in there.

Can you please tell me what I'm doing wrong?

Thank you very much.

Performance degraded when using ArrayList for OneToMany relationship

When doing a commit of a persist of an entity that has a OneToMany relationship to another entity and that ToMany relationship is provided as a List in the entity and the list implementation is an ArrayList, there is a performance impact compared to the List being a Vector. The reason for this is that we always cast the list Object to Vector which generates an exception which is completely unnecessary. Like other places in the eclipse link code, we can check to see if the object's class is the right type before doing the cast. The code will behave the same way but avoid the cost of generating a stack trace.

I have done measurements of doing 100,000 persist commits and used IBM JDK's health center to measure the cost of the VectorContainerPolicy.cloneFor method and found with the exception approach it takes an average of 26 microseconds per call of the method. With the new version of the code that is provided in pull request #80 it takes only 2.1 microseconds. Additionally I took the average CPU time of the last 50,000 commits of a persist of with an entity and saw a reduction from 167 ms per commit to 127 ms per commit. Both of these measurements show a good reason to make the changes proposed in pull #80.

NullPointerException in Oracle DCN listener at first callback

Our system ran into a NPE directly when the Oracle DCN listener was called from the DB the first time.
The problem seems to be here:

eclipselink/foundation/org.eclipse.persistence.oracle/src/org/eclipse/persistence/platform/database/oracle/dcn/OracleChangeNotificationListener.java

Lines 212 to 216 in 3668d1a

	CacheKey cacheKey = event.getChangeSet().getActiveCacheKey();
	if (cacheKey == null) {
	cacheKey = event.getSession().getParent().getIdentityMapAccessorInstance().getIdentityMapManager().getCacheKeyForObject(id, descriptor.getJavaClass(), descriptor, false);
	}
	cacheKey.setTransactionId(event.getSession().getProperty(ORA_TRANSACTION_ID));

where the NPE occurred at the last line.
It looks like event.getSession().get... returned null. Is this a valid return value, or is there a bug somewhere else?
I worked around this problem by just putting the rest of the method into a if (cacheKey != null) {...} block.

Map JDK 8 type Instant to TIMESTAMP instead of LONGVARBINARY

JPA 2.2 defined that a subset of the (then) new JSR 310 date/time types were to be mapped automatically by the JPA implementation.

Unfortunately, the Instant type wasn't among those types being specified.

Hibernate and DataNucleus map these to TIMESTAMP, while EclipseLink just serialises the object into LONGVARBINARY, which makes it an opaque blob in the database.

As pre-cursor to add this forgotten type to the JPA spec, it might be good for EclipseLink to align with Hibernate and DataNucleus.

Also see this SO question:
https://stackoverflow.com/q/50142822/472792

Bug #542491: New persistence property to override parameter binding defaults

Linking to BZ #542491

Security Execption in Eclipselink 2.7.4-RC2

Exception in thread "main" java.lang.SecurityException: class "javax.persistence.Persistence"'s signer information does not match signer information of other classes in the same package