to 1) Any other session will read the data modified by your transaction as it was before your "BEGIN" statement as long your transaction didn't commit. As soon your transaction committed, it will read the new value of the counter. The point being that others don't have to wait and will always see a consistent data base.
EDIT: If you dislike locking the whole table with an "ACCESS EXCLUSIVE" lock, you could also use an "Advisory Lock" (see section 13.3.4 in the link above).
SQL Server doesn't know that it is SSRS sending it a query. So the query from SSRS will run like any other query.
It's more likely be that the query optimiser decides to use a table lock for the SSRS query. of course, it could be a different problem, but that's a different question
Best Answer
No it does not create a read or write lock on films table as this creates ACCESS SHARE LOCK;
to test this open two sessions
in session one run this command
then in the second session run this command
If you need to lock films table you have to issue a Lock like so
this will block the table from updates but not reads...
NOTE Access Share Locks block any transaction that try to acquire an ACCESS EXCLUSIVE locks such as DROP Films etc...