There are certain situations where something will happen to the principal server and it won't be able to synchronize without reestablishing the mirroring sessions. But if you are in high-safety mode and have a witness server setup it should be possible for DBA to get caught up with DBB.
This is explained a bit more in books online in the Role Switching section under "How Automatic Failover Works"
If the principal server is still running, it changes the state of the principal database to DISCONNECTED and disconnects all clients from the principal database.
The witness and mirror servers register that the principal server is unavailable.
If any log is waiting in the redo queue, the mirror server finishes rolling forward the mirror database.
The former mirror database moves online as the new principal database, and recovery cleans up all uncommitted transactions by rolling them back as quickly as possible. Locks isolate those transactions.
When the former principal server rejoins the session, it recognizes that its failover partner now owns the principal role. The former principal server takes on the role of mirror, making its database the mirror database. The new mirror server synchronizes the new mirror database with the principal database as quickly as possible. As soon as the new mirror server has resynchronized the databases, failover is again possible, but in the reverse direction.
So in your situation if/when DBA comes back online it should eventually get caught up with DBB but how long it will take depends on how fast the system is, the recent work load, and the amount of log in the redo queue.