0

Passing from glassfish3 to payara5 one piece of code stop waorking. Our code save a date to a set of record and the select those updated record. In glassfish3 work seamlessly, in payara5 the select return no record (seems like it does work in another transaction). If the result is different we throw an exception, so the data is never saved. The transaction scope is READ_COMMITTED

            try {
                String whereClause = " where "
                    + "em.mailboxToBeUsed =:mailbox "
                    + "and em.lastSendResult is null "
                    + "and (em.errorsNumber is null or em.errorsNumber<4) ";

                Query updateQuery = em.createQuery("update EmailTobeSended em "
                    + "set em.trysendsince=:dat " + whereClause);

                updateQuery.setParameter("mailbox", mb);
                updateQuery.setParameter("dat", key);

                int modificate = updateQuery.executeUpdate();
                em.flush();
                TypedQuery<EmailTobeSended> emlocksel = em.createQuery(
                    "select em from EmailTobeSended em WHERE em.mailboxToBeUsed =:mailbox AND "
                    + "em.trysendsince=:dat "
                    + " order by em.emailId ", EmailTobeSended.class);
                emlocksel.setParameter("mailbox", mb);
                emlocksel.setParameter("dat", key);

                res = emlocksel.getResultList();
                if (modificate != res.size()) {
                    throw new java.lang.AssertionError("Lock error on select emailtobesended");
                }

            } catch (Exception ex) {
                gotError = true;
                res = null;
            }

On glassfish3, after flushing, the second query find out the record updated. On payara5 no result

EDIT


we use eclipselink

user2946593
  • 63
  • 2
  • 11
  • Have you looked at this https://stackoverflow.com/questions/17121620/spring-data-jpa-update-query-not-updating/20056058#20056058 – Karan Sethi Oct 05 '19 at 08:52
  • @Karan Sethi : seems they are related to hibernate and not eclipselink we have no annotation on the function – user2946593 Oct 07 '19 at 10:24
  • Any way I'm looking to those suggests – user2946593 Oct 07 '19 at 10:44
  • The question isn't clear on what the outcome is. What does the value of modificate and what is within the returned res list? The only way I can see this occurring is if the EntityManager isn't part of a transaction, but this would cause the em.flush() call to throw an exception. Otherwise, this is a configuration issue or bug in your server, and you would need to show how you are getting the EntityManager and transaction – Chris Oct 13 '19 at 18:40

1 Answers1

0

WE solved the problem: it wasn't about persistence, it was about mysql versions (from 5.5 to 5.6) The DATE field was interpreted differently between the two version: in 5.5 millisecond are ignored, in 5.6 are considered. Due to the field was not configured to accept millisecond, the date were saved without them, so in the second query (a select) the comparison were done answering with ".000" as millisecond, different from what were searched Updating the field to DATE(3) solved the problem

user2946593
  • 63
  • 2
  • 11