CDV ❯ Figure out why modifying a shared object from on-load didn't give an exception

• Type: Bug
• Status: Resolved
• Priority: 2 Major
• Resolution: Won't Fix
• Component/s:
• Labels:

• Assignee: interfaces
• Reporter: stulscot
• Created: December 21, 2009
• Votes: 0
• Watchers: 3
• Updated:

  February 12, 2014
• Resolved:

  February 12, 2014

Attachments

• stulscot (839.0) text/x-java-source OnLoadTest.java
• stulscot (1.00 k) text/xml tc-config.xml

Description

Any modifications made to distributed objects don’t seem to be propagated during the on-load initialisation.

In the attached example each node adds its DsoNode to a HashSet in the method configured in the element in tc-config.xml. On the first node this is run on "nodes = [ClientID[0]]" is always output even after a second node is started. The second node always outputs "nodes = [ClientID[0], ClientID[1]]".

If line 40 of OnLoadTest.java is uncommented and the section is commented out in tc-config.xml the example works as excepted.

If this is the correct behaviour then it should be clearly stated in the documentation that code called to initialise the object when faulted in should not modify distributed objects in any way.

The example can be compiled with ‘javac -cp terracotta-api-1.1.0.jar OnLoadTest.java’.

Comments

Steve Harris 2009-12-21

That’s intentionally. On-load is designed for updating transient and or local state.

Stuart Scott 2010-01-06

Since meaningful exceptions are thrown when a shared object is modified without holding a lock, would it not be appropriate in this case to also throw an exception? The current behaviour silently modifies the local instance of the shared object while not propagating changes. Also the documentation regarding this behaviour is rather vague.

Steve Harris 2010-01-06

Yeah, I’m kinda suprised it doesn’t. We’ll have to take a look

Hung Huynh 2014-02-12

DSO is discontinued