112 * This would require synchronized blocks around some potentially large 113 * bodies of code which would impact the multi-threaded scalability of 114 * the implementation. 115 * Further, if data is to be coordinated or transferred between two 116 * trackable objects then both would need to be synchronized raising 117 * the possibility of deadlock unless some strict rules of priority 118 * for the locking of the objects were established and followed 119 * religiously. 120 * Either or both of these drawbacks makes such an implementation 121 * infeasible. 122 * <p> 123 * A less conservative approach would be to change the state of the 124 * trackable object to DYNAMIC during all modifications of the data 125 * and then to change it back to STABLE after those modifications 126 * are complete. 127 * While this state transition more accurately reflects the temporary 128 * loss of tracking during the modification phase, in reality the 129 * time period of the modifications would be small in most cases 130 * and the 2 changes of state would each require synchronization. 131 * <p> 132 * In comparison the act of setting the <code>curTracker</code> 133 * reference to null in the usage pattern above effectively invalidates 134 * all outstanding <code>Tracker</code> objects as soon as possible 135 * after the change to the data and requires very little code and no 136 * synchronization to implement. 137 * <p> 138 * In the end it is up to the implementor of a StateTrackable object 139 * how fine the granularity of State updates should be managed based 140 * on the frequency and atomicity of the modifications and the 141 * consequences of returning an inaccurate State for a particularly 142 * small window of opportunity. 143 * Most implementations are likely to follow the liberal, but efficient 144 * guidelines found in the usage pattern proposed above. 145 * 146 * @since 1.7 147 */ 148 public interface StateTrackable { 149 /** 150 * An enumeration describing the current state of a trackable 151 * object. 152 * These values describe how often the complex data contained 153 * in a trackable object can be changed and whether or not it 154 * makes sense to try to track the data in its current state. | 112 * This would require synchronized blocks around some potentially large 113 * bodies of code which would impact the multi-threaded scalability of 114 * the implementation. 115 * Further, if data is to be coordinated or transferred between two 116 * trackable objects then both would need to be synchronized raising 117 * the possibility of deadlock unless some strict rules of priority 118 * for the locking of the objects were established and followed 119 * religiously. 120 * Either or both of these drawbacks makes such an implementation 121 * infeasible. 122 * <p> 123 * A less conservative approach would be to change the state of the 124 * trackable object to DYNAMIC during all modifications of the data 125 * and then to change it back to STABLE after those modifications 126 * are complete. 127 * While this state transition more accurately reflects the temporary 128 * loss of tracking during the modification phase, in reality the 129 * time period of the modifications would be small in most cases 130 * and the 2 changes of state would each require synchronization. 131 * <p> 132 * In comparison the act of setting the {@code curTracker} 133 * reference to null in the usage pattern above effectively invalidates 134 * all outstanding {@code Tracker} objects as soon as possible 135 * after the change to the data and requires very little code and no 136 * synchronization to implement. 137 * <p> 138 * In the end it is up to the implementor of a StateTrackable object 139 * how fine the granularity of State updates should be managed based 140 * on the frequency and atomicity of the modifications and the 141 * consequences of returning an inaccurate State for a particularly 142 * small window of opportunity. 143 * Most implementations are likely to follow the liberal, but efficient 144 * guidelines found in the usage pattern proposed above. 145 * 146 * @since 1.7 147 */ 148 public interface StateTrackable { 149 /** 150 * An enumeration describing the current state of a trackable 151 * object. 152 * These values describe how often the complex data contained 153 * in a trackable object can be changed and whether or not it 154 * makes sense to try to track the data in its current state. |