Sorry, I wasn't clear.
The dataManager initialization can certainly occur in every
setThreadContext method call because that's when you have the
threadContext available. But as long as you save the thread context
when setThreadContext is called, you can certainly do it in
getSession() instead - p
I think I get it now why you said put getSession in
addOrReplaceDocument. This way you construct the dataManager when you
need it as oppose to each set and clear pair : )
On 6/7/2011 5:10 PM, Farzad Valad wrote:
I don't fully understand how a connector instance can be used by
multiple threads
I don't fully understand how a connector instance can be used by
multiple threads without each thread calling setThread. Here is what I
think I know.
The contract does say that addOrReplaceDocument is only called after
setTC, right? Because you first have to have connection handle before a
The recommendation to have getSession be called in
addOrReplaceDocument is because there is nothing in the contract which
states that the connector instance will switch threads between calls.
Therefore there is no guarantee that
clearThreadContext/setThreadContext will be called right prior to
addO
Thanks for the confirmation. So if I have code to set dataManager to
null in clearThreadContext and create a dataManager in
setThreadContext. Why do I need the getSession method in
addOrReplaceDocument method? From what I learnt about ManifoldCF
architecture, setThreadContext will get called
It sounds like you are on the right track for fixing all of these problems.
Karl
On Tue, Jun 7, 2011 at 4:38 PM, Farzad Valad wrote:
> I think I found the problem. I should be tearing down the dataManager and
> recreating it between clear and set thread context calls, because it has a
> thread
I think I found the problem. I should be tearing down the dataManager
and recreating it between clear and set thread context calls, because it
has a thread context. I'm not doing that. I guess I did learn
something reading : ) let me know if you believe otherwise. Also do you
think this is
So I think I figured it out. For some reason I'm getting a db error,
bad transaction id, which then kills my dataManager object, or I should
say the framework is setting it to null. What does a Bad transaction ID
mean? Thoughts? This happened after I did a LockClean and restart both
the age
