Chapter 12. Hints and tips

AtomicAction A = new AtomicAction();
Object obj1;
Object obj2;

obj1 = new Object();			// create new object
obj2 = new Object("old");		// existing object

A.begin(0);
obj2.remember(obj1.get_uid());	// obj2 now contains reference to obj1
A.commit(true);				// obj2 saved but obj1 is not

Here, the two objects are created outside of the control of the top-level action A. obj1 is a new object. obj2 is an old existing object. When the remember method of obj2 is invoked, the object is activated and the Uid of obj1 is known. Since this action commits, the persistent state of obj2 may now contain the Uid of obj1. However, the state of obj1 itself has not been saved, since it has not been manipulated under the control of any action. In fact, unless it is modified under the control of some action later in the application, it will never be saved. However, if the constructor would have used an atomic action, the state of obj1 would have automatically been saved at the time it was constructed, preventing this inconsistency.

public class Test
{
    public Test (String s);
    ...
	private String s1;
    private String s2;
};

public Test (String s)
{
    s1 = s;
    s2 = s;
}

Here, both s1 and s2 point to the same string, and a naive implementation of the save_state method has the potential to copy the string twice. From the perspective of the save_state method, this is merely inefficient. However, it would cause the restore_state method to unpack the two strings into different areas of memory, destroying the original aliasing information. JBoss Transaction Service packs and unpacks separate object references.