Optimize JDBC update and retrieval logic

Current optimizations on JDBC Session is good but still have large rooms for optimizations. Each commit of session is resetting state of session and after that each update there is another get call for session as this by getRequestedSessionId:

 else { 
 	S session = wrappedSession.getSession(); 
 	saveSession(session); 
 	String sessionId = session.getId(); 
 	if (!isRequestedSessionIdValid() 
 			|| !sessionId.equals(getRequestedSessionId())) { 
 		SessionRepositoryFilter.this.httpSessionIdResolver.setSessionId(this, 
 				this.response, sessionId); 
 	} 
 } 

• For a simple request to server there is two commit calls.
• One of them are calling UPDATE session.
• Each commit is followed by SELECT.
• 3 SELECT, 2 UPDATE calls are triggered by each request. These are transactional and thus it around 20 SQL statements are executed per call.

I can understand that session must be committed as early as possible since client issues can happen, but following an UPDATE with a SELECT is not ideal.

Start by tracing the JDBC Session commit path around SessionRepositoryFilter and getRequestedSessionId, focusing on the two commit calls described in the issue. Compare the UPDATE and subsequent SELECT operations for a simple request. Done means reducing redundant database statements without changing session ID handling or commit behavior.