Fail fast vs fail safe

fail fast, throw exception if any concurrent modification.

fail safe, work on seperate/clean copy for modification, dont throw exception.

 java.util.concurrent.CopyOnWriteArrayList<E>

A thread-safe variant of java.util.ArrayList in which all mutative operations (add, set, and so on) are implemented by making a fresh copy of the underlying array. 

This is ordinarily too costly, but may be more efficient than alternatives when traversal operations vastly outnumber mutations, and is useful when you cannot or don't want to synchronize traversals, yet need to preclude interference among concurrent threads. The "snapshot" style iterator method uses a reference to the state of the array at the point that the iterator was created. This array never changes during the lifetime of the iterator, so interference is impossible and the iterator is guaranteed not to throw ConcurrentModificationException. The iterator will not reflect additions, removals, or changes to the list since the iterator was created. Element-changing operations on iterators themselves (remove, set, and add) are not supported. These methods throw UnsupportedOperationException. 

All elements are permitted, including null. 

Memory consistency effects: As with other concurrent collections, actions in a thread prior to placing an object into a CopyOnWriteArrayList happen-before actions subsequent to the access or removal of that element from the CopyOnWriteArrayList in another thread. 

This class is a member of the Java Collections Framework.

Fail-Safe vs Fail-Fast Iterator in Java Collections
Fail-Safe Iterator (java.util.concurrent – ConcurrentSkipListSet, CopyOnWriteArrayList, ConcurrentMap)

Fail-safe Iterator is “Weakly Consistent” and does not throw any exception if collection is modified structurally during the iteration. Such Iterator may work on clone of collection instead of original collection – such as in CopyOnWriteArrayList. While ConcurrentHashMap’s iterator returns the state of the hashtable at some point at or since the creation of iterator. Most collections under java.util.concurrent offer fail-safe Iterators to its users and that’s by Design. Fail safe collections should be preferred while writing multi-threaded applications to avoid conurrency related issues. Fail Safe Iterator is guaranteed to list elements as they existed upon construction of Iterator, and may reflect any modifications subsequent to construction (without guarantee).

Fail-Fast Iterator (java.util package – HashMap, HashSet, TreeSet, etc)

Iterator fails as soon as it realizes that the structure of the underlying data structure has been modified since the iteration has begun. Structural changes means adding, removing any element from the collection, merely updating some value in the data structure does not count for the structural modifications. It is implemented by keeping a modification count and if iterating thread realizes the changes in modification count, it throws ConcurrentModificationException. Most collections in package java.util are fail-fast by Design.

Observor and Observable

 java.util.Observable

This class represents an observable object, or "data" in the model-view paradigm. It can be subclassed to represent an object that the application wants to have observed. 

An observable object can have one or more observers. An observer may be any object that implements interface Observer. After an observable instance changes, an application calling the Observable's notifyObservers method causes all of its observers to be notified of the change by a call to their update method. 

The order in which notifications will be delivered is unspecified. The default implementation provided in the Observable class will notify Observers in the order in which they registered interest, but subclasses may change this order, use no guaranteed order, deliver notifications on separate threads, or may guarantee that their subclass follows this order, as they choose. 

Note that this notification mechanism is has nothing to do with threads and is completely separate from the wait and notify mechanism of class Object. 

When an observable object is newly created, its set of observers is empty. Two observers are considered the same if and only if the equals method returns true for them.

java.util.Observer

A class can implement the Observer interface when it wants to be informed of changes in observable objects

ajax the file input

I am trying to submit multipleĀ forms on same page at same time; with one of them being a file input.

The key is to wrap the form, using a new FormData.

  $.ajax({
    url: 'saveAttachment.do',
    type: 'POST',
    data: new FormData($('#saveAttachment')[0]),
    async: false,
    cache: false,
    contentType: false,
    processData: false,
    success: function (returndata) {
      alert(returndata);
    }
  });

subresource and prefetch

both seems would try cache first, then http request if not yet cached.

At the same time, subresource could result in duplicate http retrieval, if same resources (eg. image) initiated again from another (eg.css). Because, subresource always force to download.

While, as prefetch is low priority, since it’s supposed for next page. So it waits for current page loading finish. And prefetch could be cancelled by subresource or any other initiation of same resource.

for example, with below source code:

<!-- below would be reinitiated/requested by css later -->
<link rel="subresource" href="images/header_brs.jpg" />
<link rel="subresource" href="images/float_bar_lg.gif" />
<link rel="prefetch" href="images/grad.jpg" />
<link rel="prefetch" href="images/brs_C.jpg" />
<!-- JS for next page -->
<link rel="prefetch" href="js/summaryPage.js" />
<link rel="subresource" href="js/summaryPage.js" />

it would render as below

prefetch_brs_C_jpg

prefetch_grad_jpg

prefetch_subresource_next_page_summaryPage_js

subresource_float_bar_lg_gif

subresource_header_brs_jpg

JVM 7

http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-VM/html/memleaks.html

3.1.1 Detail Message: Java heap space

The detail message Java heap space indicates that an object could not be allocated in the Java heap. This error does not necessarily imply a memory leak. The problem can be as simple as a configuration issue, where the specified heap size (or the default size, if not specified) is insufficient for the application.

In other cases, and in particular for a long-lived application, the message might be an indication that the application is unintentionally holding references to objects, and this prevents the objects from being garbage collected. This is the Java language equivalent of a memory leak. Note that APIs that are called by an application could also be unintentionally holding object references.

3.1.2 Detail Message: PermGen space

The detail message PermGen space indicates that the permanent generation is full. The permanent generation is the area of the heap where class and method objects are stored. If an application loads a very large number of classes, then the size of the permanent generation might need to be increased using the -XX:MaxPermSize option.

Interned java.lang.String objects are no longer stored in the permanent generation. The java.lang.String class maintains a pool of strings. When the intern method is invoked, the method checks the pool to see if an equal string is already in the pool. If there is, then the intern method returns it; otherwise it adds the string to the pool. In more precise terms, the java.lang.String.intern method is used to obtain the canonical representation of the string; the result is a reference to the same class instance that would be returned if that string appeared as a literal.

When this kind of error occurs, the text ClassLoader.defineClass might appear near the top of the stack trace that is printed.