sql - Is there a point to wrapping a stored procedure in a transaction if no try/catch or exception logic to rollback is used? -

i have noticed company has lot of stored procedure scripts similar this:

alter procedure myprocedure     @itemid int     begin transaction     -- stuff, maybe 1 insert/update statement, maybe many     commit transaction 

the point is, there no try/catch blocks, , no 'if' statements rollback. rollback never used anywhere in code.

so point of transaction, then? there other benefits wrapping inside transaction don't know about? thought reason use rollback if goes wrong.

could there logic outside scope of procedure gives meaning this?

given limited knowledge, not seem pointless seems dangerous because if goes wrong, commit never executed (correct?), , have open transaction , table locked indefinitely.

if update fails part way through rollback (well more fail commit, amounts rollback) when session closes. it's discussed in detail here, relevant part is:

transactions ... has no persistent effect whatever on database, through: action of rollback statement, abnormal termination of client requesting transaction, or abnormal termination of transaction dbms. may action system (deadlock resolution) or administrative agent, or may abnormal termination of dbms itself. in latter case, dbms must roll active transactions during recovery.

basically have set procedure never partially executes. said, may not ideal way due performance , locking concerns, without more specifics couldn't say.