[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Session recovery on rollback
by adrian@jboss.org
You are still confusing different things.
The JMS Session is not the same as the transaction.
In fact, with transaction interleaving it is perfectly legal
(and more efficient) to do the following which JBossMQ actually supports:
1) Enlist session in tx1
2) receive message 1 (this is in the session, but actually belongs to tx1)
3) delist session
4) Enlist session in tx2
5) receive message 2 (into tx2)
6) commit tx1 (this does NOT commit the session, it commits the transaction, i.e. message 1)
Again, there is a test for this in the JBossMQ testsuite.
Similarly, these could be different sessions on different threads
receiving from the same queue.
The idea of the JIRA task is that step 5 would not receive message 2
until step 6 either commits or rollbacks message 1. If it rolls back
then step 5 gets message 1.
This maintains a GLOBAL ordering across transactions/threads/sessions,
something that is not a spec requirement, but some people have
asked for.
I wouldn't recomend somebody uses this, unless they aren't worried
about throughput. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958136#3958136
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958136
19 years, 8 months
[Design of JBoss Build System] - Eclipse plugin for Maven versus Maven plugin for Eclipse
by tuomas_kiviaho
mvn eclipse:eclipse is not the only available option to automate eclipse project mapping to pom.xml. The Maven 2.x Plug-in for Eclipse <http://m2eclipse.codehaus.org/> doesn't generate static .classpath entries from pom.xml but instead tries to map the whole pom (and it's parents) as one dynamic classpath variable. "Mavenizing" of a project is merely Maven>Enable from project pop-up menu. The approach is more transparent to the user since modifications to the pom.xml are visible to the user directly. Modifications to the parent pom.xml are noted are noted as well but not instantly.
Drawback in this approach is that instead of mapping workspace projects the mapping is currently done to maven repositories. There is work being done to get the pom.xml aftifact resolution to prefer workspace projects over repository artifacts .<http://jira.codehaus.org/browse/MNGECLIPSE-59>
By using separate checkout location (complete maven tree model consisting of module & parent relations from SCM) from workspace and picking up preferred projects to workspace as indirect references to the checkout location gives more control over workspace. And the best part is that mvn commands can still be done to the checkout location since it is maven compliant. Non recursive usage of mvn let's you drop part of the tree.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958099#3958099
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958099
19 years, 8 months