static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/transaction.html
In proxy mode (which is the default), only external method calls coming in through the proxy are intercepted. This means that self-invocation, in effect, a method within the target object calling another method of the target object, will not lead to an actual transaction at runtime even if the invoked method is marked with @Transactional.
Consider the use of AspectJ mode (see mode attribute in table below) if you expect self-invocations to be wrapped with transactions as well. In this case, there will not be a proxy in the first place; instead, the target class will be weaved (that is, its byte code will be modified) in order to turn @Transactional into runtime behavior on any kind of method.
1.Create Manifest file with following entries
a.Class-Path: <lib1.jar> <lib2.jar> <path/lib3.jar>
b.Main-Class: <classname>
c.Place a new line at the end of this file
2. use "jar" command to create jar
jar cvfm <your_jar_file.jar> <manifest_file> <class_files> <libraries>
3. To execute jar using unix command
java -jar <your_jar_file.jar>
This section describes some semantics of transaction propagation in Spring. Please note that this section is not an introduction to transaction propagation proper; rather it details some of the semantics regarding transaction propagation in Spring.
In Spring-managed transactions, be aware of the difference between physical and logical transactions, and how the propagation setting applies to this difference.
PROPAGATION_REQUIRED
When the propagation setting is PROPAGATION_REQUIRED, a logical transaction scope is created for each method upon which the setting is applied. Each such logical transaction scope can determine rollback-only status individually, with an outer transaction scope being logically independent from the inner transaction scope. Of course, in case of standard PROPAGATION_REQUIRED behavior, all these scopes will be mapped to the same physical transaction. So a rollback-only marker set in the inner transaction scope does affect the outer transaction's chance to actually commit (as you would expect it to).
However, in the case where an inner transaction scope sets the rollback-only marker, the outer transaction has not decided on the rollback itself, and so the rollback (silently triggered by the inner transaction scope) is unexpected. A corresponding UnexpectedRollbackException is thrown at that point. This is expected behavior so that the caller of a transaction can never be misled to assume that a commit was performed when it really was not. So if an inner transaction (of which the outer caller is not aware) silently marks a transaction as rollback-only, the outer caller still calls commit. The outer caller needs to receive an UnexpectedRollbackException to indicate clearly that a rollback was performed instead.
PROPAGATION_REQUIRES_NEW
PROPAGATION_REQUIRES_NEW, in contrast to PROPAGATION_REQUIRED, uses a completely independent transaction for each affected transaction scope. In that case, the underlying physical transactions are different and hence can commit or roll back independently, with an outer transaction not affected by an inner transaction's rollback status.
where clause (or any other clause). The associated objects are also not returned directly in the query results. Instead, they may be accessed via the parent object. The only reason you might need an alias is if you are recursively join fetching a further collectionSpecify the parameter name in the name attribute. <input type = "submit" name = "update" value = "Update" /> <input type = "submit" name = "delete" value = "Delete" /> Include the "params" attribute, with the corresponding parameter name as value, in the annotation for request mapping @RequestMapping(..., params = "update") public ModelAndView updateCustomer(...) { ... } @RequestMapping(..., params = "delete") public ModelAndView deleteCustomer(...) { ... }
Add <configuration> entry in standalone.xml<subsystem xmlns="urn:jboss:domain:web:1.0" default-virtual-server="default-host">
...
<configuration>
<jsp-configuration development="true"/>
</configuration>
</subsystem>Temporary files can be found in standalone/tmp/vfs 