Java Async Flashcards
Asynchronous I/O
Similar to non-blocking I/O. The I/O call returns immediately without waiting for the operation to complete.
Blocking I/O
Process is blocked until all bytes are read or written. E.g. for a network device, if the user wrote 1000 bytes, then the OS would only unblock the process after the write() call completes. Easy to use but what if operation fails?
Non-blocking I/O
OS only reads or writes as many bytes as is possible without blocking the process. Returns quickly but is more work to implement
Difference between asynchronous and non-blocking I/O
a non-blocking read() returns immediately with whatever data is available
an asynchronous read() requests a transfer that will be performed in its entirety, but that will complete at some future time
Synchronous / blocking example
A Java or PHP web server handles IO or network requests. If the code reads from a file or database, your code “blocks” everything after it from executing. So your machine is holding onto memory and processing time for a thread that isn’t doing anything
Asynchronous / non-blocking example
A Node js server only uses one thread to service all requests. When the code needs to query the database, it sends a callback to a second queue and the main thread continues running.
Promise
used to keep track of whether the asynchronous event has been executed or not and determine what happens after the event occurs. 3 states = pending, resolved, rejected
Async
Allows us to write promises based code as if it was synchronous and checks that we are not breaking the execution thread. Makes sure a promise is returned and if it is not returned then it automatically wraps it in a promise resolved with its value
Await
Makes code wait until promise returns a result
Future
a future represents the result of an asynchronous operation. When an async function is called, it returns an uncompleted future. If that function succeeds, the future completes with a value. Otherwise, it completes with an error
Database isolation
allows a transaction to execute as if there are no other concurrently running transactions. Goal is to prevent reads/writes of temporary or incomplete data written by concurrent transactions. Only feasible if developer can guarantee no race conditions
Database consistency
if two clients can see different states at the same time, their view of the database is inconsistent. Sequential consistency = all threads can agree on a consistent, global sequential ordering or writes.
Database deadlock avoidance
transactions should always access tables in the same order, so no two transactions deadlock waiting on the table from the other. Wait-die -> older transactions must wait for younger one to release data items (higher aborts and rollbacks). Wait-wound -> older transactions never wait for younger transactions (fewer aborts and rollbacks)
