My application uses a JDBC connection and it only has one thread (main) at the moment. The service methods commit the changes whenever required. There are some places where iterating the collection is necessary. Based on the result, I may have to change the data (and hence a commit).
Given this, should I start a transaction before the collection is read? I am sure that this process is not going to change the data. I just want to save some runtime openSession and closeSession if they are not really required.

You should always use a Transaction even for read only data.

Allow me to ask a stupid question - Why is it necessary to have a transaction for a read only operation? If the data will never be updated, what purpose does the transaction serve?

Not a silly question as lots of people assume you don't need one as well.
Its all a question of data consistency. Many database vendors will add a read lock when doing selects, also database data caching etc are tied to the transaction model. The transaction manages these aspects. I think people get the idea of no transactions necessary due to the use of auto-commit being on by default for standard JDBC connections. The black magic just happens - the transaction is there in reality. In hibernate the transaction auto-commit is off so you must do it.

auto-commit doesn't really mean "no transactions". it means "a new transaction for every statement", and is usually slower than no autocommit

Again, this might be a silly question! Suppose, I begin a transaction for a read-only operation and I couldn't find what I wanted from the collection, should I do a rollback or commit? At this point, is there a difference in the low-levels between rollback and commit?

I am asking this because I always do a commit before close for any operation that did not produce any exception and I want to make sure that I am okay for the scenario I explained above.

Thanks!
Madhan.

One more addition to my question... Should I necessarily do either a rollback or commit?

commit is ok