Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Current Events
Join our developers event to win one of the valuable prizes!
posted 5 years ago
viewed 5429 times
Share this article

CUBRID Driver Improvements in CUBRID 8.4.1

We have recently released a new version of CUBRID 8.4.1. At the time we announced over 70% performance increase for INSERT and UPDATE operations as well as new SQL functions and Regular Expression support. In this blog I will tell more about other changes we have introduced in CUBRID 8.4.1 related to its API.

New parameters in the connection string

Debugging Logs

In 8.4.1 we have added several new parameters which allow to turn ON and OFF the debugging logs directly through connection URLs. See this example:

url = "jdbc:cubrid:localhost:33000:demodb:::?logOnException=true&logSlowQueries=true&slowQueryThresholdMillis=1000

  • logOnException: if set to true, various Exceptions can be logged.
  • logSlowQueries: if set to true, slow queries will be logged for further analysis and tuning.
  • slowQueryThresholdMillis: a parameter determines the time of query execution in milliseconds after which the query is defined as slow. This parameter is effective if logSlowQueries = true.

Thus, developers can easily configure the CUBRID server to enter into debugging mode and log the necessary information.

Query Timeout

In CUBRID 8.4.1 we have added a few more new parameters to the connection URL:

  • queryTimeout: to set the query execution timeout in seconds (default: 0 sec., infinite). This value can be modified in the code using the setQueryTimeout() method.
  • connectTimeout: to set the connection timeout value in seconds (default value: 0). This value  also  can be configured by DriverManger.setLoginTimeout() method in JDBC. However, if this value is configured in the connection URL, the value configured by this method is ignored.

url = "jdbc:cubrid:localhost:33000:demodb:::?rctime=600&queryTimeout=1&connectTimeout=5

Improved performance of CUBRID Drivers

Most CUBRID Drivers such as PHP and Python are based on CUBRID CCI Driver. The following figure illustrates the structure of API Dependency. In this CUBRID 8.4.1 version we have fixed several bugs in CCI and introduced a few functions which significantly improve the performance of CCI and its dependent drivers.

Figure 1: CUBRID API Dependency Structure.

Figure 1: CUBRID API Dependency Structure.

New cci_prepare_and_execute() function

CUBRID CCI driver now provides a new cci_prepare_and_execute() function which allows to increase the performance of SELECT queries by 45%. This functions allows to PREPARE and EXECUTE a query in a single call instead of calling cubrid_prepare() and cubrid_execute() functions separately.

In PHP both cubrid_query() and cubrid_execute() functions now work in PREPARE and EXECUTE mode by default when the connection object and query are passed into the functions as input parameters. Otherwise they perform regular querying or execution.

Improved cci_close_req_handle() function

The cci_close_req_handle() has been improved to reduce the number of message transmissions by sending the exit request and the request handle number to the next PREPARE, instead of CAS. This modification also effectively eliminated the case of returning the -4 (COMMUNICATION ERROR) error when it calls cci_close_req_handle() after CAS has been restarted with the auto-commit mode ON.

Improved JDBC driver

We have improved the performance of the JDBC driver which now collects the header information in a buffer then sends them in a single attempt.

Bug Fixes and Modifications

    1. Fixed a cci_set_query behavior error.
      Previously, the query timeout would not behave as intended when setting the timeout by using cci_set_query_timeout(). This problem is now fixed.
    2. Fixed a problem which would occur in HA mode in which a CCI-based application would not attempt to reestablish the connection with the priority host when it has been failed back.
      For example, in the above case, a CCI-based application would not attempt to reestablish the connection with the main host configured before the althost of the connection URL when it has been failed back, preventing it from reconnecting to the master server. This problem has been fixed.
    3. Fixed a problem in which performing the CLOSE operation on a certain query request handler in a CCI, PHP, or ODBC application would affect the commit status of other query request handlers.
      Previously, performing the CLOSE operation on the req1 of a certain query request handler in a CCI, PHP, or ODBC-based application would affect the commit status of the req2 of a different query request handler. This problem has been solved.
      The following is a case scenario that caused a problem in earlier versions. In this scenario, the system would refer to the req1 and its erroneous auto commit mode at the time of  CLOSE(req1) despite auto commit mode being turned off after EXECUTE(req1). This caused req2 to be unexpectedly changed as well.
        req1 = PREPARE 
        req2 = PREPARE 
    4. Fixed a problem in which transactions would not be rolled back once an error occurred during the PREPARE function call in an application such as CCI, PHP, ODBC, or OLE DB.
      Previously, transactions would not be rolled back once an error occurred during the PREPARE function call in an application such as CCI, PHP, ODBC, or OLE DB. This problem has been solved.
    5. Fixed a problem in which a CCI interfacebased application for Linux would malfunction when the value of network socket file descriptors exceeds 1,024.
      Previously, a CCI interface-based application for Linux would malfunction when the value of network socket file descriptors exceeded 1,024. In this condition, the application would end up referring to an incorrect memory address due to the limitation of select(), a function used to implement the CCI interface. For this reason, the application would be abnormally terminated or a communication error would occur. This problem has been solved.
    6. Fixed a problem in which the cci_datasource_borrow function might immediately return an error without waiting for the connection to be established at the function call.
      Previously, the cci_datasource_borrow function might immediately return the "All connections are used" error without waiting for the connection to be established at the function call as specified in max_wait. This problem has been solved.
    7. Fixed a problem in which a memory leak would occur when statement pooling has been set by using the DATASOURCE in the CCI interface.
      Previously, a memory leak would occur when statement pooling has been set by using the DATASOURCE in the CCI interface. This problem has been fixed.
    8. CCI Fixed a problem in which an application that was developed with the CCI interface would malfunction when COMMUNICATION ERROR occurs.
      Previously, in an application that was developed with the CCI interface,  "COMMUNICATION ERROR net_read_header()" would cause the application to malfunction. This problem has been solved by adding a functionality that can be used to verify functional errors of the network.
    9. Removed the cap on the size of data that can be entered with a single request in the JDBC driver.
      Previously, the size of data that could be entered with a single request (for example, a request made by using methods such as execute or executeBatch in a JAVA application) in the JDBC driver was capped at 100MB. This cap has been removed. In CUBRID 2008 R4.0 Patch 2 and earlier versions, exceeding this cap would result in the following error:
      Java.lang.ArrayIndexOutOfBoundsException : 1024
      At cubrid.jdbc.jci.UOutputBuffer.writeByte( : 607)

    More changes which refer to other aspects of CUBRID 8.4.1 can be found in the Release Notes.

    comments powered by Disqus