Np, one sec...
On 07/30/2013 07:06 AM, Greg Huber wrote:
Glen,
OK, can you make the changes to the trunk so i can switch to hibernate.
On 30 July 2013 11:47, Glen Mazza <glen.ma...@gmail.com> wrote:
Much appreciated. I was thinking it may be good for us to run on
Hibernate for a few weeks anyway, even if EclipseLink were running
perfectly, just to see if there are any kinks with it where our code needs
to be tightened up. I can fix EclipseLink's problem in the interim so
if/when *Hibernate* has a kink, we know we can always immediately flip back
to EclipseLink while fixing the Hibernate issue.
Glen
On 07/30/2013 06:39 AM, Greg Huber wrote:
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/**>
**<http://docs.oracle.com/**javaee/**6/api/javax/**persistence/**<http://docs.oracle.com/javaee/**6/api/javax/persistence/**>
FlushModeType.html<http://**do**cs.oracle.com/javaee/6/api/**<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/****<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<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://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/**>
<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/**<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
