Q:

What is the new JDBC 4.3 Connection Request feature with `beginRequest` & `endRequest` methods? 

The JDBC 4.3 update arrived with Java 9 2017-10.  Amongst its few changes is the new feature on Connection where the beginRequest and endRequest methods signals…

Hints to the driver that a request, an independent unit of work, is beginning on this connection.  Each request is independent of all other requests with regard to state local to the connection either on the client or the server.  Work done between beginRequest, endRequest pairs does not depend on any other work done on the connection either as part of another request or outside of any request.  A request may include multiple transactions.  There may be dependencies on committed database state as that is not local to the connection. 

…and…

… is optional, vendor specific and should largely be transparent.  

➠ Please explain the purpose of this feature.  
It seems to be about something larger than transactions yet is not about two-phase commits.  Is it related to sharding, the major new feature in JDBC 4.3? 

Is it some kind of scope that wraps around multiple transactions? 
What databases make use of this feature?  

In particular, does Postgres, H2, or or Microsoft SQL Server have such a feature? 

I am not asking about whether these databases have JDBC drivers updated yet for JDBC 4.3 yet.  I am asking about the bigger picture, what is the meaning and purpose of a "request" in the context of a database connection across connections. 
Oddly, the JDBC 4.3 specification makes only this one mention, with no explanation:

JDBC API changes
The following changes were made to existing JDBC interfaces..
java.sql. Connection
Added the methods beginRequest,endRequest, setShardingKey,
  setShardingKeyIfValid. 

A:

These new JDBC4.3 APIs beginRequest and endRequest have to do with connection management.  It's really a hint provided by the connection pool to the driver that a connection has been checked out of the pool (beginRequest) or checked back into the pool (endRequest).  Without these APIs the driver has really no clue about request boundaries.  The driver can then use these request demarcations to do dirty laundry like pinging the database, replacing the connection without another one for load balancing, clearing out dirty states, etc. 
These APIs were defined as Oracle specific APIs in the Oracle JDBC thin driver before JDBC4.3.  Oracle's UCP (Universal Connection Pool) already calls these APIs.  Now that they are part of the standard, other connection pools can start using them (and other drivers will implement them).