Java Distributed Technologies: RMI, JDBC, JMS and Two Worked Exam Traces

Memorising RMI, JDBC, JMS, sockets and servlets as separate abbreviations does not explain what happens when a remote operation is slow, duplicated or only partly completed. One model covers all five: every call that crosses a process boundary can succeed, fail outright, or succeed without ever telling the caller. Two cases show what that costs: an RMI reservation whose reply is lost after the database commit, and a two-client stock race repaired by one guarded SQL update.

1. Java distributed technologies: the concept map

A distributed Java application places components in separate processes, JVMs or hosts. Across that boundary, serialization, latency, concurrency and partial failure matter. An in-process call uses local references, and both sides usually share one failure domain.

JDBC accesses a database and naming provides discovery. Neither is a transport between services, so a design that needs one cannot borrow the other to do that job. If you are building the wider Java and DSA base underneath all of this, the Coding & DSA Courses for Placements track covers it.

2. Java RMI: interface, registry, stub and serialization

The contract declares InventoryService extends java.rmi.Remote. Its reserve(String requestId, String sku, int units) method returns a serializable Reservation and declares throws RemoteException. The server exports an implementation and binds it as inventory; the client looks up that name and calls through a stub or proxy.

A normal call is stub serialization, network transfer, server dispatch, result or exception serialization, and client reconstruction. Ordinary serializable objects cross by value as copies; exported remote objects cross by remote reference. Server skeletons belonged to the original 1.1 stub protocol; from Java 2 onwards the runtime dispatches reflectively, so a separately generated skeleton is historical terminology rather than something you write today.

RemoteException reports communication failure, not business outcome. A missing reply cannot reveal whether state changed, so state-changing retries need idempotency.

3. Worked RMI trace: 7 units, a 44 ms call and a lost reply

The client calls reserve("ORD-204", "PEN-9", 3) when database stock is 7. Success returns Reservation("ORD-204", "PEN-9", 3, 4, true). Assume the following per-hop costs. A real network moves every one of them, but the shape of the total stays the same.

1. Client marshalling takes 2 ms.

2. Outbound network time is 18 ms.

3. Server validation, JDBC work and response marshalling take 5 ms.

4. Return network time is 18 ms, and client unmarshalling takes 1 ms.

5. Total time is 2 + 18 + 5 + 18 + 1 = 44 ms. Five identical sequential calls cost 5 × 44 = 220 ms, which shows why chatty remote interfaces are expensive.

The server receives ORD-204, reduces stock from 7 to 4, commits, and prepares success. If the reply is lost, the client sees failure although the reservation exists. A blind retry can change 4 to 1. Storing the unique request key ORD-204 beside the result lets a retry return that result while stock stays 4. This is application-level idempotency, not exactly-once delivery.

4. RMI, sockets, HTTP, JMS and JDBC: choose by responsibility

These technologies combine naturally: HTTP may enter a servlet, an order component may call inventory through RMI, inventory may use JDBC, and a commit may lead to a JMS event. A raw socket sits underneath all of them, and you open one directly only when you also want to own framing, timeouts and reconnection yourself. Each arrow has its own failure boundary. The Application Layer Protocols: DNS and HTTP Guide develops request-response at the network side. HTTP does not guarantee business idempotency or remove partial failures.

5. JDBC concurrency trace: two clients reserve 3 from stock 5

Clients A and B each request 3 units of PEN-9 from stock 5. With a separate SELECT qty and unguarded update, both can read 5, approve 3, and write 2. The row ends at 2, but the system promised 6 from 5, overcommitting by 1.

Use one atomic statement instead:

UPDATE inventory SET qty = qty - 3 WHERE sku = 'PEN-9' AND qty >= 3;

Client A executes first. Update count 1 means success, changing 5 to 2. Client B then gets update count 0 because 2 >= 3 is false. Only 3 units are promised and stock remains 2.

Disable auto-commit, perform the guarded update, insert the reservation, then commit. Roll back if either statement fails. The lost update shown here is one of a small family of concurrency anomalies, and DBMS Concurrency Problems MCQs works through the rest. This JDBC transaction does not automatically include an earlier RMI call or later JMS publish in one distributed atomic transaction.

6. Java messaging and naming: what happens after the commit

After commit, consider StockReserved{eventId:"EVT-204", orderId:"ORD-204", sku:"PEN-9", units:3, remaining:4}. A JMS queue distributes work among consumers; a topic publishes to subscriptions. Ordering and redelivery guarantees differ from broker to broker, so check your provider's settings before depending on either.

Messaging separates caller waiting time from downstream work, but duplicates and restarts still require idempotent consumers. Recording EVT-204 lets a consumer ignore redelivery.

The RMI registry maps inventory to a remote reference; JNDI is a broader naming and directory API. Neither carries the payload. CORBA and Java IDL supply a language-neutral ORB speaking IIOP, which earns its place when non-Java clients must call the same objects and rarely otherwise.

7. Java distributed technologies exam patterns and traps

For “notify several independent subscribers after a reservation”, choose a JMS topic because it publishes to separate subscriptions. For “call a Java remote object's typed method and receive a result synchronously”, choose RMI because it provides synchronous object-style invocation.

8. Java distributed technologies: the short version and next step

Use this 75-minute revision order:

1. 10 minutes: redraw the technology map.

2. 15 minutes: trace registry, stub, serialization and return.

3. 20 minutes: recompute 7 -> 4, 44 ms and the lost-reply retry.

4. 15 minutes: reproduce the stock 5, request 3, and update-count 1/0 trace.

5. 15 minutes: answer the eight selection and trap checks in section 7.

Choose the API by responsibility. Treat every network call as a partial-failure boundary. Make state-changing retries idempotent. Let the database enforce contested invariants atomically. An ORD-204 retry must leave stock at 4, not 1.

If you want structured Core and Advanced Java study with practice, continue with Java Course: Concepts, MCQs and Coding Questions. As a final self-test, start with stock 10 and request 4: without deduplication, two executions leave 2; an idempotent retry leaves 6.