It depends on what type of recovery happens.
In a normal recovery, such as when your application program does a rollback or the application program is terminated for some reason without doing a commit or rollback (that automatically causes a rollback), then you will not lock TableA or TableB during
the recovery. All a rollback recovery does is read the database log, and apply before images to updated rows. So the rollback does not depend in any way upon TableA or TableB and will get no locks on those tables.
But if the whole database instance fails, for example, the database server is rebooted (note this is the server your database is on, not the box you are running your INSERT on), then when the server comes back up, the entire database will be locked out until
the recovery completes. So in that case, TableA and TableB (and everything else in your database) will be unavailable until the recovery completes. Note that this applies whether or not you are in a transaction state. If you were not in transaction
state and were running an INSERT (or UPDATE or DELETE) that took 10 minutes to run, and the server was rebooted 9 minutes into that update, the recovery of that database would likely take several minutes (often as long as the original update had been running)
and during that time your entire database would be unavailable.
For that reason, (and other problems, like your log getting large), long running updates and transactions are often best avoided in systems which have high availability requirements. If you must do them, try to do them during times when other load
and uptime requirements are minimal (nighttime, weekends, etc).
Tom