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/** > 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/** > 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://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 >>>>>> >>>>>> >>>>>> >>>>>> >
