[
https://issues.redhat.com/browse/TEIID-5887?page=com.atlassian.jira.plugi...
]
Steven Hawkins commented on TEIID-5887:
---------------------------------------
@rareddy Here's the WIP:
https://github.com/teiid/teiid/compare/master...shawkins:TEIID-5887?expand=1
The strategy here is to create marshallers that don't need to be unregistered. For
now I'm assuming a one to one relationship between a resource adapter and the
translator and that the source table schemas aren't modifiable - changing those
assumptions would mean changing the simplistic caching strategy. I'll need to have
more test cases, but the basic idea is that our marshalling provider can have everything
registered and we just need a little help when asked to find by class. It would be great
if there were another method on their marshalling provider that asked by object.
From there the effects of the filter are being moved to post
serialization logic. I have that stubbed, but not wired in yet.
Issues with marhaller registration
----------------------------------
Key: TEIID-5887
URL:
https://issues.redhat.com/browse/TEIID-5887
Project: Teiid
Issue Type: Bug
Components: Infinispan
Reporter: Steven Hawkins
Priority: Major
Fix For: 13.1
Original Estimate: 6 hours
Remaining Estimate: 6 hours
Adding transactional logic to infinispan highlights several problems with marshaller
registration. The first is that all connections are working off of a shared context and
each registering a marshaller for the same class type - this is not thread safe.
The other issue specific to transactions is that some operations are delayed or redone at
commit time - which is called after the connection is closed potentially in a different
thread and thus the marshaller provider has been removed. Given the interplay of threads
using a thread local won't work.
Potentially a transaction aware thread pool or the use of something like our execution
context keep alive may be needed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)