11:37 a.m.
[
https://issues.jboss.org/browse/ISPN-1140?page=com.atlassian.jira.plugin....
]
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