Thanks Ron. It would be great if you could add comments to the JIRA
issue here with your findings.
https://issues.apache.org/roller/browse/ROL-1761
I hope to investigate later this week.
--a.
Ron Peterson wrote:
2008-11-24_22:22:59-0500 rpeterso:
2008-11-21_11:49:48-0500 Anil Gangolli <[EMAIL PROTECTED]>:
I am not seeing any flush() on the persistence strategy in this code
path at all, which (assuming READ_COMMITTED transaction isolation)
suggests that there may also not be proper exclusion across multiple
threads/hosts. A flush() would be needed on registering the lease as
well as releasing the lease. I think in this case the manager
(ThreadManager) actually should be doing this. Allan, if you're around
can you verify ?
I also tried adding flush() statements to
org/apache/roller/weblogger/business/jpa/JPAThreadManagerImpl.java to
match the Hibernate code, but didn't notice any affect. Should there be
flush() statements here to match HibernateThreadManagerImpl.java?
Well, there's no difference as far as my task running and my page
updating goes. However, if I turn on debug logging to watch my SQL
execute, adding the flush() statements to JPAThreadManagerImpl.java
results in the UPDATE roller_tasklock statements being completed with a
COMMIT, rather than a ROLLBACK. And of course the table now updates as
expected also.
I don't know the codebase well enough to know if I really fixed
everything, but at least it's working better than it was.
