Friday, April 3, 2009

EJB 3 Slight Perfomance Increasing tips

Most of the people who code EJB 3 which i have seen so far are reluctant to override the defaults provided by the container. Specially when it comes to transactions handling. In EJB 3 a session bean's method's default transaction type is REQUIRED. So we keep this as it is in most cases and sometimes just use REQUIRES_NEW if we want to do a batch process withouth haulting the current transaction.
But what most of us forget is that methods such as find(),getReference() and flush() do not need a transaction in order to perform the required function. By keeping the container defaults you are unnecessarily burning the container by starting unwanted Transactions.
So next time when you are using these methods make sure to mark the transaction type as NOT_SUPPORTED an opposed to NEVER because NOT_SUPPORTED only blocks the current transaction until the end of the method where as NEVER throws a remote exception.

String builder/buffer performance

If you ever wanted to do string manipultion what you would turn to would be one of the following as opposed to using raw String objects which we know is not good for string manipulation due to the object construction on the heap. But the only issue with String builder/buffer is that even those it has append methods, it does not have a clear method which would clear out the buffer and enable the user to start fresh. There are two ways in which you can achieve this;
    StringBuilder str = new StringBuilder();
    From the above two methods it is said that performance vice it is always advisable to use the later method of setting the length to zero which will start appending strings from the zeroth position again rather than deleting the already existing strings within the buffer.

Hibernate load vs get

In my current project where we are using spring-hibernate we faced an issue where at certain times stale objects were being manipulated when tested on concurrent access. When doing throught the specs we were able to nail down the issue which was basically the way the methods load and get works in hibernate. According to the specs, the load method populated that respective entity object with cached results where as get method fetched it from the database.
So when ever you want to do a batch operation as i see it, its always better to use load method to achieve better performance where as you should use the get method if you are regularly updating and recovering data from a particular table.
If your a EJB 3 EntityManager fan then this same can be achieved through the getReference() method which is the same as the load method in hibernate.

Simple Select SQL Tips

Simple Select SQL Tips;
Recently i was trying to optimize my SQL statements to increase the overall performance of the application that im currently working on. I have a friend who is working as a DBA at a reputed company so i decided to get his assitence so that i can reduce some research time.
He was talking about alot of ways to increase performance databases but what i didnt know which he told me was about SQL joins. I always prefer writting joins using aliases rather than using the JOIN/OUTER JOIN keywords. But according what he said when you write join statements using aliases, it is in the end converted to JOIN/OUTER JOIN statement type by the database. So for example if you write an alias join statement as;
Select * from Customer a, Phone b where a.phone_id =;
It is infact converted to the following query by the database;
Select * from Customer INNER JOIN Phone ON;
So you can get better performance by writting your queries in the latter order, yet i still prefer aliases as it is more readable. But then again, the Customer usually doesnt care about code readability but performance. So its a compromise between maintenance vs efficiancy.

Oracle Outer Join Simplified

If your using oracle, you do not need to use the OUTER JOIN keyword when you are joining tables as oracle has its own syntax. You can use the below comman to outer join tables in oracle;
select * from passenger a, reservation b where a.res_id(+) =;

Google goes black

In the times of recession it seems that Google has stepped into make a mark by contributing to saving energy by providing users with a black screen Google which is said to lower energy consumption. IMHO it does have some kind of coolness added to it. Maybe black metal rock fans will kinda like googling on this ;) ....

Check it out @