[infinispan-issues] [JBoss JIRA] Commented: (ISPN-1140) TransientMortalCacheEntry has incorrect implementation of setValue()

[Steven Newson (JIRA)]

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

Steven Newson commented on ISPN-1140:
-------------------------------------

Sorry, I wasn't clear. I'm using the TRANSACTIONAL mode but I'm not in a JTA container. That means that all of my cache operations go via the NonTxInvocationContext. When the code gets to the InvocationContextContainerImpl it recognises that there is not a running transaction and forces the code down the "Non-transactional" route.

This is totally the behaviour I want. I will ultimately be deploying this application into a server with a JTA container (we deploy to multiple containers as our clients use different ones). However, my development team want to be able to run the application locally (from within Eclipse) and deploy to Tomcat without having to have a JTA container present. In development, we just don't care about JTA. Also, when I'm creating JUnit tests, I don't want to have to start a JTA container in order to run the test. If the commit fails then the test has failed - I'm not worried about the cache becoming stale / corrupted in that environment.

For reference, my test looks a bit like this:

{code:java}
public void testLoadSaveLoadCaching() {
  MyDomainClass first = new MyDomainClass("ABC", "ABC123");
  save(first);

  long id = first.id;

  MyDomainClass second = load(id);

  assertEquals("Should have same code", "ABC", second.code);
  assertEquals("Should have correct description", "ABC123", second.description);

  second.description = "DEF123";

  update(second);

  MyDomainClass third = load(id);

  assertEquals("Should have same code", "ABC", third.code);
  assertEquals("Should have correct description", "DEF123", third.description);
}


@Entity(name = "MyDomainClass")
@Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL)
public static class MyDomainClass {

  @Id
  @Basic
  @Column(name = "id")
  public long   id;

  @Basic
  @Column(length = 4)
  public String code;

  @Basic
  @Column(length = 10)
  public String description;
}
{code}



> TransientMortalCacheEntry has incorrect implementation of setValue()
> --------------------------------------------------------------------
>
>                 Key: ISPN-1140
>                 URL: https://issues.jboss.org/browse/ISPN-1140
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Core API
>    Affects Versions: 4.2.1.FINAL, 5.0.0.CR3
>            Reporter: Steven Newson
>            Assignee: Galder Zamarreño
>             Fix For: 5.0.0.CR4, 5.0.0.FINAL
>
>
> The implementation of {{setValue()}} in {{TransientMortalCacheEntry}} is as follows
> {code:java}
>    public Object setValue(Object value) {
>       return cacheValue.maxIdle;
>    }
> {code}
> This leads to problems in the {{DefaultDataContainer}} as the following {{put()}} code has no effect:
> {code:java}
> public void put(Object k, Object v, long lifespan, long maxIdle) {
>   InternalCacheEntry e = entries.get(k);
>   if (e != null) {
>      e.setValue(v);
>      InternalCacheEntry original = e;
>      e = entryFactory.update(e, lifespan, maxIdle);
>      // we have the same instance. So we need to reincarnate.
>      if(original == e) {
>         e.reincarnate();
>      }
>   } else {
>      // this is a brand-new entry
>      e = entryFactory.createNewEntry(k, v, lifespan, maxIdle);
>   }
>   entries.put(k, e);
> }
> {code}
> The effect of this for me is that when I am not in a JTA enviroment and I take the following steps via Hibernate the result is not cached correctly:
> - Insert record into table via Hibernate
> - Reload record by its ID
> - Change non-ID field on the record
> - Update the record via Hibernate
> - Reload the record by its ID
> - Check that the value reloaded matches the updated value
> The 2nd level cache always returns the first inserted record rather than the updated one. Each Hibernate access is inside its own transaction.
> I fixed this locally by overriding the class in the classpath, replacing the {{setValue()}} method with the following implementation:
> {code:java}
> public Object setValue(Object value) {
>    Object original = cacheValue.value;
>    cacheValue.value = value;
>    return original;
> }
> {code}
> Which also corresponds to the (misspelled :)) Javadoc:
> {noformat}Sets the value of the entry, returing the previous value{noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira