Я не могу видеть запись обновления после сброса - PullRequest
Новая
       52

Я не могу видеть запись обновления после сброса

0 голосов
/ 05 октября 2019

Переход от glassfish3 к payara5 один кусок кода перестает работать. Наш код сохраняет дату в наборе записей и выбирает те обновленные записи. В glassfish3 работают без проблем, в payara5 select не возвращает запись (похоже, что он работает в другой транзакции). Если результат отличается, мы генерируем исключение, поэтому данные никогда не сохраняются. Объем транзакции: 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;
            }

На glassfish3, после очистки, во втором запросе выясняется, что запись обновлена. На payara5 нет результата

РЕДАКТИРОВАТЬ

мы используем eclipselink

1 Ответ

0 голосов
/ 15 октября 2019

МЫ решили проблему: речь шла не о постоянстве, а о версиях mysql (от 5.5 до 5.6). Поле DATE интерпретировалось по-разному для двух версий: в 5,5 миллисекунды игнорируются, в 5,6 рассматриваются. Из-за того, что поле не было сконфигурировано для приема миллисекунд, даты были сохранены без них, поэтому во втором запросе (выборка) сравнение было выполнено с ответом «.000» в виде миллисекунды, в отличие от того, что искали Обновление поля до DATE(3) решил проблему

...