OK, if you open a remote connection from your terminal that is in front of you to the system that is hosting your application, you use TCP/IP - Transmission Control Protocol & Internet Protocol - for which rules exist regarding those connections.
In the briefest possible summary, you trigger the connection, which causes a behind-the-scenes negotiation between your "network stack" software and the server's "network stack" software. Part of the negotiation is that you not only open a connection to an IP address but also to a specific port number at that address. The port is actually just a generated number that allows you to have more than one connection from your terminal to your destination at the same time, as might happen if you connected through two different windows on the same machine. One might use port number 44129 and the other port would be 44130, for example.
Earlier you said,
In any way RA allow only one user at a time
If you open a session and suddenly the network drops out, you have to reconnect that session - but most systems do not allow a "reconnect" because that is how folks break into systems - through reconnecting dangling connections. So most systems are configured to not allow this. Which means that if you didn't crash the operation when the connection drops (which is significantly possible), then you have a session that you cannot close. Here are the three scenarios that could result from the drop, and the specific perils of each:
1. The dropped session triggers a disconnect event (analogous to a form_close event but with a network connection) that causes a cascade of events to eventually cause your application on the server to terminate abruptly. If it had been in the middle of a partially complete transaction that wasn't protected by a BEGIN/COMMIT sequence, then you wouldn't roll back to a "safe" spot and your database just became inconsistent.
2. The drop occurred but the application dismissed the event and refused to close because it knew it had a partial transaction pending. But... since you cannot reconnect to the dropped connection because of the rules about "reconnect" attempts described above, you can now never finish that transaction because you can't get into that session again to "back it out" or complete the operation.
3. The drop didn't trigger an abort AND your "single-user-at-a-time" case doesn't apply. The database can STILL be locked out for other users because something in the incomplete transaction has a buffer locked and everyone trying to get in gets only so far before they can't access the data in the locked buffer.
In cases 2 and 3, the only way out of that mess is to reboot the server AND THEN do a compact and repair on the database AND THEN (with users still locked out) try to determine if any table contains a partially started transaction that should have been committed because it involved multiple tables. Then you have to back out the parts that should have been protected by a BEGIN/COMMIT style of coding.
That is the chopping edge you are nearing.
