Glen, I was trying to add the usecase but ran into the howto debug issue. I will sort the test if I manage to get the debug working.
Cheers Greg On 30 July 2013 11:05, Glen Mazza <glen.ma...@gmail.com> wrote: > Let me play with it today before throwing in the towel and going with > Hibernate. Even if we jump to Hibernate I still need to figure out the > EclipseLink matter so our coding is not dependent on one JPA framework > alone, we should be able to work with both or have a JIRA ticket with > EclipseLink. I'd like to add in a JUnit test case that would have caught > this regression. > > Glen > > On 07/30/2013 03:31 AM, Greg Huber wrote: > >> Glen, >> >> Commenting out the FlushModeType.COMMIT makes no difference, (assumes it >> switches to auto). Would have thought that createNamedQuery or >> createQuery >> would behave the same way as they both follow the same logic in roller. >> Where one works and one does not, maybe an EclipseLink issue. I am no >> expert but with hibernate this does not happen. >> >> For me, eclipse does not have a good track record wrt QA, and with orm >> there is just no workaround. It would simpler if we can switch to >> something that works without all this pain. >> >> Cheers Greg >> >> >> On 29 July 2013 14:27, Glen Mazza <glen.ma...@gmail.com> wrote: >> >> This page: >> http://docs.oracle.com/javaee/****6/api/javax/persistence/**<http://docs.oracle.com/javaee/**6/api/javax/persistence/**> >>> FlushModeType.html<http://**docs.oracle.com/javaee/6/api/** >>> javax/persistence/**FlushModeType.html<http://docs.oracle.com/javaee/6/api/javax/persistence/FlushModeType.html>>says >>> "If |FlushModeType.COMMIT| is set, the effect of updates made to >>> entities in the persistence context upon queries is unspecified", which >>> is >>> different from the definition of COMMIT below (where it *only* occurs at >>> a >>> transaction commit.) If I understand that correctly, that would mean >>> Roller can't rely on a flush having occurred or not with COMMIT, and >>> EclipseLink and any other JPA implementation is welcome to go either way, >>> and can indeed behave differently between named and dynamic queries, as >>> EclipseLink does. >>> >>> Might the problem be with our code? We're relying on unspecified >>> functionality when we set FlushModeType to COMMIT, and we've been lucky >>> so >>> far that OpenJPA and Hibernate just so happen to flush data (as it's >>> allowed to do per the spec) while EclipseLink is choosing not to. I >>> wonder >>> if we should have new versions of NamedQuery and DynamicQuery that >>> *don't* >>> set it to COMMIT (assuming the default of AUTO is being used otherwise, >>> as >>> specified here: http://www.eclipse.org/**** >>> eclipselink/documentation/2.5/****<http://www.eclipse.org/**eclipselink/documentation/2.5/**> >>> jpa/extensions/p_persistence_****context_flushmode.htm)--****something< >>> http://www.eclipse.**org/eclipselink/documentation/** >>> 2.5/jpa/extensions/p_**persistence_context_flushmode.**htm)--something<http://www.eclipse.org/eclipselink/documentation/2.5/jpa/extensions/p_persistence_context_flushmode.htm)--something>>that >>> the Media File stuff could apparently use here. >>> >>> Glen >>> >>> >>> On 07/29/2013 08:32 AM, Greg Huber wrote: >>> >>> Glen, >>>> >>>> I think its only on the named queries as if I delete a weblog entry it >>>> updates correctly, and uses a dynamic query. >>>> >>>> EntityManager em = getEntityManager(false); >>>> Query q = em.createNamedQuery(queryName)****; >>>> // Never flush for queries. Roller code assumes this behavior >>>> q.setFlushMode(FlushModeType.****COMMIT); >>>> return q; >>>> >>>> EntityManager em = getEntityManager(false); >>>> Query q = em.createQuery(queryString); >>>> // Never flush for queries. Roller code assumes this behavior >>>> q.setFlushMode(FlushModeType.****COMMIT); >>>> >>>> >>>> Cheers Greg >>>> >>>> On 29 July 2013 13:14, Glen Mazza <glen.ma...@gmail.com> wrote: >>>> >>>> OK, we can switch to Hibernate for the time being, and it works fine >>>> >>>>> there, it's as simple a matter as commenting-out the EclipseLink >>>>> dependency >>>>> and uncommenting the Hibernate one in the app/pom.xml and doing an mvn >>>>> clean install to get a new WAR. Still, I'd like to fix this >>>>> EclipseLink >>>>> issue, maybe there's some simple setting causing it not to work. Note >>>>> our >>>>> EclipseLink is JPA 2.1 vs. Hibernate's (and the OpenJPA's) 2.0, that >>>>> might >>>>> be part of the story. >>>>> >>>>> Glen >>>>> >>>>> On 07/29/2013 07:34 AM, Greg Huber wrote: >>>>> >>>>> From google: >>>>> >>>>>> "By default, the database flush mode is set to AUTO. This means that >>>>>> the >>>>>> Entity-Manager performs a flush operation automatically as needed. In >>>>>> general, this occurs at the end of a transaction for >>>>>> transaction-scoped >>>>>> EntityManagers and when the persistence context is closed for >>>>>> application-managed or extendedscope EntityManagers. In addition, if >>>>>> entities with pending changes are used in a query, the persistence >>>>>> provider >>>>>> will flush changes to the database before executing the query.If the >>>>>> flush >>>>>> mode is set to COMMIT, the persistence provider will only synchronize >>>>>> with >>>>>> the database when the transaction commits.However, you should be >>>>>> careful >>>>>> with this, as it will be your responsibility to synchronize entity >>>>>> state >>>>>> with the database before executing a query. If you don’t do this and >>>>>> an >>>>>> EntityManager<http://docs.****or**acle.com/javaee/6/api/**javax/**<http://acle.com/javaee/6/api/javax/**> >>>>>> <http://oracle.com/**javaee/6/api/javax/**<http://oracle.com/javaee/6/api/javax/**> >>>>>> > >>>>>> persistence/EntityManager.****html<http://docs.oracle.com/** >>>>>> javaee/6/api/javax/****persistence/EntityManager.**html< >>>>>> http://docs.oracle.com/**javaee/6/api/javax/** >>>>>> persistence/EntityManager.html<http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html> >>>>>> **> >>>>>> **> >>>>>> **>query >>>>>> returns stale entities from the database, the application can wind up >>>>>> in an inconsistent state." >>>>>> >>>>>> Did try to change it to auto but made no difference. >>>>>> >>>>>> On 29 July 2013 12:25, Glen Mazza <glen.ma...@gmail.com> wrote: >>>>>> >>>>>> OK, I'll check, but what happens if you go to the Roller >>>>>> maintenance >>>>>> tab >>>>>> >>>>>> and click on "Flush blog" (that will normally empty out the cache) -- >>>>>>> problem solved then? >>>>>>> >>>>>>> Note I had to bring back your changes after the move to fewer >>>>>>> modules, >>>>>>> I >>>>>>> might have missed something. >>>>>>> >>>>>>> Glen >>>>>>> >>>>>>> On 07/29/2013 07:20 AM, Greg Huber wrote: >>>>>>> >>>>>>> Glen, >>>>>>> >>>>>>> Can you test whether you can delete a media file folder? ie add a >>>>>>>> folder >>>>>>>> and then try and delete it. For me it seems to delete it OK but >>>>>>>> when >>>>>>>> you >>>>>>>> refresh the media file folder view it is still there. If I then >>>>>>>> shut >>>>>>>> down >>>>>>>> tomcat and restart it is gone. It seems something to do with its >>>>>>>> cache? >>>>>>>> >>>>>>>> checking: >>>>>>>> >>>>>>>> public Query getNamedQuery(String queryName) >>>>>>>> .... >>>>>>>> q.setFlushMode(FlushModeType.********COMMIT); >>>>>>>> >>>>>>>> it sets the query to flush on commit, which should in theory flush >>>>>>>> the >>>>>>>> query cache when the transaction is committed. >>>>>>>> >>>>>>>> Is there some callback method we need to call to get it to flush? >>>>>>>> >>>>>>>> >>>>>>>> Cheers Greg >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >
