[infinispan-issues] [JBoss JIRA] (ISPN-9306) Unguarded lazy initialization of SQL statements in JDBC CacheStore

[Sanne Grinovero (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594695#comment-13594695 ] 

Sanne Grinovero commented on ISPN-9306:
---------------------------------------

Example, taking some code from {{AbstractTableManager}}:

{code:java}
protected String deleteRowSql;

public String getDeleteRowSql() {
      if (deleteRowSql == null) {
         deleteRowSql = String.format("DELETE FROM %s WHERE %s = ?", getTableName(), config.idColumnName());
      }
      return deleteRowSql;
}
{code}

It's not strictly wrong - especially it might seem to work fine in single threaded tests or servers with a limited amount of cores, but it becomes a huge red flag for the kind of situations Infinispan is used for.

Assuming I understand correctly, the method {{getDeleteRowSql()}} is invoked by multiple independent threads sharing the same instance of the table manager, which makes it troublesome.

The simplest solution is to either mark the method as {{synchronized}} or the field as {{volatile}} yet both could have other annoying effects on performance optimisations; best would be to initialize all such things into a final field, but that requires a bit of refactoring to ensure you have the table names, column names, etc.. during the contractor invocation.


> Unguarded lazy initialization of SQL statements in JDBC CacheStore
> ------------------------------------------------------------------
>
>                 Key: ISPN-9306
>                 URL: https://issues.jboss.org/browse/ISPN-9306
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Loaders and Stores
>    Affects Versions: 9.3.0.CR1
>            Reporter: Sanne Grinovero
>            Assignee: Ryan Emerson
>
> Several fields in {{org.infinispan.persistence.jdbc.table.management.AbstractTableManager}} are lazily initialized by its child implementations, yet without any barrier.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)