Friday, November 23, 2012
Unix commands
1.Delete a file:
rm filename
2.Delete a directory and its contents
rm -rf directoryName/
3.To give permission to execute:
sudo chmod 755 jdk-6u21-linux-i586.bin
4.Copy to remote system
scp -r /home/rocky/ROOT15Sep.war user@192.168.0.60:/home/user/
4.To change user password:
passwd rocky
[enter new paasword]
5.Find and kill jboss process
ps -ef | grep jboss
sudo kill -9 6789
6.Rename system name
http://www.makeuseof.com/tag/change-computer-ubuntu-1010/
7. text search in files under a folder
find myDir -type f -name *.txt -exec grep "hello" {} /dev/null \;
Note: Here search text is "hello", folder is "myDir", file name is in the format "*.txt"
Creation of executable JAR file with dependent libraries
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>
Tuesday, November 13, 2012
C3P0 Connection Pool Configuration Rules of Thumb
http://javatech.org/2007/11/c3p0-connectionpool-configuration-rules-of-thumb/
C3P0 is a fantastic open source ConnectionPool that is feature rich, stable, and positively production ready. I personally like it more than DBCP because there is too much blocking encountered when checking in/out connections with DBCP. C3P0 dodges that problem with an asynchronous return to the pool, but you might end up using a lot more connections than you need to if you're not careful. Here's a list of the most important C3P0 settings and good production settings to use – along with some words of wisdom as to why the change from default is a good thing.
acquireIncrement=5 default(3) Batching the retrieval of Connections is wise because the process of opening a Connection is expensive. Why do it 5 times instead of once? The downside to this is that you may only need the one connection. Read on to maxIdleTime settings to make sure idle connections make their way back into the pool.
maxIdleTime=3600 default(0) Setting the maxIdleTime to a non-zero value permits C3P0 to remove Connections from the pool and freeing up database resources. This will never happen when maxIdleTime is set to 0. Setting to a small value might have Connections being retrieved and returned on too frequent a basis to be practical, so I've picked 3600 seconds ( 1 hour ) as a nice happy medium. Once the peak traffic is over, then the connections can be returned.
maxIdleTimeExcessConnections=300 default(0) You need to set this in addition to maxIdleTime to have the Connections removed from the pool and returned to the DB.
maxPoolSize=100 default(15) You'll have to fine tune this setting base on your own individual situation, but it's important to keep this on the largish side for the simple reason that C3P0 doesn't synchronously return connections to the pool. The implication of this is that the pool should actually be sized slightly larger than what you think the maximum number of Connections needed at peak time would be. For more on this, see numHelperThreads.
minPoolSize=20 default(3) This one too can be fine tuned based on your individual needs, but let's just say that you don't always want to be returning all your Connections and having to reacquire new ones. 20 is a good size to allow for handling of new bursts of sporadic traffic w/o having to reacquire them.
numHelperThreads=6 default(3) This is a very important property if you're going to have large bursts of traffic on your site. C3P0 ( as was alluded to previously ) doesn't return connections to the pool synchronously and as a result doesn't have the same issues with blocking that DBCP has. However, as a result, Connections are not made available until some arbitrary time after they are returned to the pool. C3P0 has helperThreads which are responsible for doing the actual return work and making them available. Under large load I've experienced times where these spikes could require 400 Connections using the default setting of 3. Using 6 HelperThreads will keep this spike under 100 connections. If you can afford the connections or won't have huge loads on the system, then the default of 3 will probably be fine for you.
unreturnedConnectionTimeout=3600 default(0) I've set this to 1 hour. If a Connection is used for longer than an hour, then C3P0 will assume it's been orphaned and will reclaim the Connection to the pool – closing it in the process.
acquireIncrement=5 default(3) Batching the retrieval of Connections is wise because the process of opening a Connection is expensive. Why do it 5 times instead of once? The downside to this is that you may only need the one connection. Read on to maxIdleTime settings to make sure idle connections make their way back into the pool.
maxIdleTime=3600 default(0) Setting the maxIdleTime to a non-zero value permits C3P0 to remove Connections from the pool and freeing up database resources. This will never happen when maxIdleTime is set to 0. Setting to a small value might have Connections being retrieved and returned on too frequent a basis to be practical, so I've picked 3600 seconds ( 1 hour ) as a nice happy medium. Once the peak traffic is over, then the connections can be returned.
maxIdleTimeExcessConnections=300 default(0) You need to set this in addition to maxIdleTime to have the Connections removed from the pool and returned to the DB.
maxPoolSize=100 default(15) You'll have to fine tune this setting base on your own individual situation, but it's important to keep this on the largish side for the simple reason that C3P0 doesn't synchronously return connections to the pool. The implication of this is that the pool should actually be sized slightly larger than what you think the maximum number of Connections needed at peak time would be. For more on this, see numHelperThreads.
minPoolSize=20 default(3) This one too can be fine tuned based on your individual needs, but let's just say that you don't always want to be returning all your Connections and having to reacquire new ones. 20 is a good size to allow for handling of new bursts of sporadic traffic w/o having to reacquire them.
numHelperThreads=6 default(3) This is a very important property if you're going to have large bursts of traffic on your site. C3P0 ( as was alluded to previously ) doesn't return connections to the pool synchronously and as a result doesn't have the same issues with blocking that DBCP has. However, as a result, Connections are not made available until some arbitrary time after they are returned to the pool. C3P0 has helperThreads which are responsible for doing the actual return work and making them available. Under large load I've experienced times where these spikes could require 400 Connections using the default setting of 3. Using 6 HelperThreads will keep this spike under 100 connections. If you can afford the connections or won't have huge loads on the system, then the default of 3 will probably be fine for you.
unreturnedConnectionTimeout=3600 default(0) I've set this to 1 hour. If a Connection is used for longer than an hour, then C3P0 will assume it's been orphaned and will reclaim the Connection to the pool – closing it in the process.
Wednesday, November 7, 2012
Friday, November 2, 2012
Spring Transaction propagation: required and requires new
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/transaction.html#tx-propagation
Transaction propagation
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.
Thursday, November 1, 2012
HQL - left join vs left join fetch
Official hibernate reference
A "fetch" join allows associations or collections of values to be initialized along with their parent objects using a single select. This is particularly useful in the case of a collection. It effectively overrides the outer join and lazy declarations of the mapping file for associations and collections.
A fetch join does not usually need to assign an alias, because the associated objects should not be used in the
A "fetch" join allows associations or collections of values to be initialized along with their parent objects using a single select. This is particularly useful in the case of a collection. It effectively overrides the outer join and lazy declarations of the mapping file for associations and collections.
A fetch join does not usually need to assign an alias, because the associated objects should not be used in the
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 collection
Subscribe to:
Posts (Atom)