[JBoss Tools (users)] - Problems using
by bernie_h
Hello!
I'm using the latest version of JBoss Tools (3.0.0GA) together with a fresh installation of EclipseEE 3.4.2 and JBoss AS 4.2.3 for Seam development.
I switched from an alpha version of JBoss Tools and ran into a weird problem when using the full-publish and auto-publish function.
Here's the scenario:
I deploy a new seam app and modify some java-code.
The class-file is then automatically published to the server and I want to restart the application in order to reload the changed class.
What makes me wonder is that even a full-publish from the server-view in eclipse does not restart the application - it only makes the hibernate entitymanager-factory close and re-open again - at least that's what I see in the logs.
I always have to touch the application.xml or web.xml to force my application to restart and re-load the class-files.
Is there any way to do this in eclipse, since the alpha-version of Jboss Tools did exactly what I need? When I changed some xhtml-file only those were published to the server (without any persistence-unit to re-initialize) and when I changed some java-code I had to do a "full publish" which triggered the application-reload in Jboss AS.
It's also weird that a simple xhtml change/save-action results in a re-initialization of the persitence-unit, is there a good reason for this?
Maybe I'm doing something wrong or did not find those features.
I hope somebody can help me.
Best regards,
Bernie
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223441#4223441
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223441
15 years, 9 months
[JBoss Cache: Core Edition] - Re: JPA/Hibernate JBC usage
by zeravlai
Just to remember,
test case is T1 and T2 concurrently reading and entity from cache and T2 writing(modifying) that entity. I've tested 4 cases, which answers your question:
1.- PESSIMISTIC, R_R, T1 and T2 reading the entity from cache with em.find(). When T2 tries to write the entity the RL is upgraded to WL. T2 DOES NOT BLOCK till T1 commits.
2.- PESSIMISTIC, R_C, T1 and T2 reading the entity from cache with em.find(). Same behaviour as 1.
3.- PESSIMISTIC, R_R, T1 reads the entity with em.find(), T2 reads a set of entities with em.createNamedQuery(). Since T2 does not have a RL on the entity, T2 BLOCKS trying to acquire a WL till T1 commits. Then T2 proceeds.
4.- PESSIMISTIC, R_C, T1 reads the entity with em.find(), T2 reads a set of entities with em.createNamedQuery(). Same behaviour as 3.
Only test case 3 complies with what's written in the hibernate guide.
Also, READ COMMITTED semantic is being overwritten by Hibernate 1st level cache. That's why a re-read in T1 of the same entity (after T2 commited) will always have R_R semantics.
BTW: JBC version is 3.0.2. I'll be testing the same with MVCC and let you know.!!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223429#4223429
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223429
15 years, 9 months