Pooling Mechanism for JDBC PreparedStatement / Thread Safe Servlet
To make JSP or Servlet on Apache Tomcat really Thread Safe, JDBC PreparedStatement must be ready for unlimited concurrent access. The pooling mechanism of JDBC PreparedStatement makes it possible.
By the sophisticated Thread control of our Java API, a few lines of code are enough for your JSP or Servlet to use JDBC PreparedStatement in a really Thread Safe way.
Depending on this API, another Java API from OOP-Research can save the HTTP POST request itself into the SQL table, regardless whether its encode is application/x-www-form-urlencoded or multipart/form-data.
On this page, Java API and articles related with JDBC for JSP or Servlet are listed.
||: Product by OOP-Research
||: Documentation written by OOP-Research
||: Patch for the other vendor's system
This Java API is usefull when your JSP/Servlet accepts the file upload request with multipart/form-data encoding. By the help of this Java API, JSP/Servlet on Apache Tomcat saves the binary contents of the uploaded file into the SQL table. At this time, this Java API issues the unique ID for each file. JSP/Servlet can store this unique ID into another SQL table within the web application. With this ID specified, this Java API retriveaves the binary contents of the uploaded file from the SQL table. And the Servlet in this Java API can send back the binary contents of the uploaded file along with the appropriate content-type header.
By the help of this Java API, your DAO (Data Access Object) need not include any source code related with JNDI or JDBC.
If JNDI DataSource is available in your environment, this Java API looks up JNDI DataSource on JNDI InitialContext and establishes JDBC Connection.
Otherwise, this Java API gets JDBC Connection from JDBC driver.
Or, if you use OOP PooledStatement, this Java API can take the advantage of its pooling mechanism.
In any case, it creates JDBC PreparedStatement based on the available JDBC Connection.
On the JDBC PreparedStatement, this Java API can insert the arbitrary number of Java objects and values.
And it executes the JDBC PreparedStatement.
By this Java API, a few lines of codes are enough for your DAO (Data Access Object).
As described above, this Java API creates JDBC PreparedStatement, by the way suitable for your environment.
This means you can make your Web Applications more portable.
Please download and try this Java API.
This Java API stores the HTTP request parameters into the SQL table through JDBC. The unique ID is issued for each request, and another JSP / Servlet can use it to get the parameter values later.
Within the SQL table, the parameter values are stored in the form of URL-encoded String. Regardless of the configuration of the SQL database, the request parameters in the various charsets (including the 2 byte character such as Japanese Shift_JIS, Chinese BIG5, Chinese GB2312 or Russian KOI8-R) can be stored into the single database.
This strategy also eliminates the unnecessary byte-to-String conversion.
With its easy programming interface, a few lines of code are enough for your interactive web applications and WAP services on Apache Tomcat.
JDBC PreparedStatement can be pooled and re-used repleatedly.
This simple fact gives us the significant performance improvement. And OOP PooledStatement API has prepared all you need. With the easy programming interface of this API, our Java code for accessing to SQL table can be the quite simple one. In the multi thread environment like JSP (Java Server Pages) or Servlet, the JDBC connection and PreparedStatement can be shared among threads. By this way, your JSP or Servlets on Apache Tomcat can be really Thread Safe.
No more Cookie! No more Realm! You may have shouted during your JSP / Servlet programming. But don't worry.
Voilà, OOP LoginManager!
OOP LoginManager takes over all your tedious tasks required for the access privilege control and the session management.
By the easy programming interface of this Java API, a few lines of code are enough for the session tracking on your JSP/Servlets without Cookie. At the very first stage of your web application, the user will be asked to type the user name and password. Only for the authenticated user, the unique session ID will be issued. And the subsequent requests to your JSP/Servlets can be verified by this session ID. Then, this session ID tells your JSP/Servlets who is the user and to which groups (or Roles) s/he belongs. Of cource, similar to HttpSession object, you can associate any Java objects with the session ID.
The user name, password and groups (or Roles) are read from SQL table through JDBC PreparedStatement, and you can update these information on demand while your server is running. Your JSP/Servlets no longer needs to depend on the user authentication mechanism implemented by the JSP/Servlet server, such as BASIC authentication FORM of the Realm implementation by Apache Tomcat.
All the APIs for Servlet/JSP introduced by this web site are now included in Bento framework:
To download the APIs and source code examples, please visit the web site of Bento framework.
- Simpler than JSTL or Apache Struts
- MVC framework by HTML
- Input validation from CGI FORM
- Easy user authentication
- Easy localization (L10n)