Steve,
(I'm including tc-users in the discussion so others can chime in...)
To answer your questions:
1. We have customers who use Terracotta with other bytecode
instrumentation and it plays nicely. That being said, it's always
possible that there will be some bad interaction that we haven't
seen. What I usually tell people is that you should try it to see if
it works for the specific thing you're worried about.
2. You got that pretty much right. Someone from the DSO team might
want to chime in here.
3. When the server receives a lock request for a greedily held lock
from a client that doesn't hold the lock, the server sends a lock
retrieval message to the client that does have it greedily. It is
then up to the client that does have it greedily to return control of
the lock to the server. There are no fairness guarantees (nor, AFAIK,
are there fairness guarantees in the JVM, but I could be totally wrong
about that). I'm also pretty sure that there is no special priority
given to the activity of return the lock to the server.
Saravanan can answer the greedy lock question much better than me,
though, since he wrote it.
Cheers,
Orion
On Feb 14, 2008, at 1:59 PM, Steve Millidge wrote:
> Orion,
>
> Thanks for the clarifications. A couple of questions which arose
> during the
> talk.
>
> Does the byte code instrumentation conflict with any other bytecode
> instrumentation which may be added to the code by Wily Introscope or
> by code
> coverage tools or JDO/EJB3 implementations?
>
> What happens if a client crashes during a transaction, is the
> transaction
> rolled back? I guessed not and said the behaviour would be like
> normal Java
> behaviour, the exception would pop up through the lock and any
> changes up to
> that point would be committed. Is that true?
>
> I've also got a question on Greedy Locks, how does the server call
> back to
> the client application to ask for the Greedy Lock to be released? Is
> it
> possible for there to be a large delay if the Client application is
> very
> busy and can't respond to the lock release request? When I used to
> work for
> Object Design as a PS consultant on the ObjectStore product, which
> had a
> very similar distributed caching architecture, they used to have a
> separate
> process on each host machine that the server talked to which used to
> keep
> track of object locks and communicated with the cluster clients via
> shared
> memory. This ensured that locks could be released without having to
> rely on
> the client to respond.
>
> Thanks
>
> Steve
>
_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users
