erasure not reified

erasure not reified

1   public class T {

2       public static void main(String[] args) throws Exception {

3           A<String,B> a = new A<String,B>();

4           B b = a.get("hello");

5       }

6

7       static class B {}

8

9       static class A<K,V> {

10          V get(K k) {

11              Object obj = get_object_for(k);

12              V v = (V)obj;

13              return v;

14          }

15          Object get_object_for(K k) {

16              return flipcoin() ? new Object() : new B();

17          }

18

19          boolean flipcoin() {

20              return (Math.random()*10)%2 < 1;

21          }

22      }

23  }

This will fail at line number 4 whenever flipcoin returns true, (and one would

hope it to fail at line number 12 so at least we can catch ClassCastException

and handle it), what if I want to check in A.get if object retured from

get_object_for is an instanceof B or not and handle accordingly but

I can’t do that due to generic type erasure might have worked if it were reified.

Advertisements

interpret caliper results

for caliper results like

20% Scenario{vm=java, trial=1, benchmark=WithGettersAndSetters, memoryMax=-Xmx512M} 36.39 ns; ?=0.26 ns @ 3 trials, allocated 1 instances for a total of 32B
36.39 ns is median of time it took in each reps
?=0.26 is std dev

and use reps parameter passed to timeMethod to iterate over computation to benchmark.

Container-Managed Transaction Demarcation for Session and Entity Beans

ejb-3_0-fr-spec-ejbcore

13.6.2 Container-Managed Transaction Demarcation for Session and Entity Beans

13.6.2.1 NOT_SUPPORTED

The container invokes an enterprise bean method whose transaction attribute is set to the NOT_SUPPORTED value with an unspecified transaction context.

If a client calls with a transaction context, the container suspends the association of the transaction context with the current thread before invoking the enterprise bean’s business method.

The container resumes the suspended association when the business method has completed. The suspended transaction context of the client is not passed to the resource managers or other enterprise bean objects that are invoked from the business method. If the business method invokes other enterprise beans, the container passes no transaction context with the invocation.

Refer to Subsection 13.6.5 for more details of how the container can implement this case.

13.6.2.2 REQUIRED

The container must invoke an enterprise bean method whose transaction attribute is set to the REQUIRED value with a valid transaction context.

If a client invokes the enterprise bean’s method while the client is associated with a transaction context, the container invokes the enterprise bean’s method in the client’s transaction context.

If the client invokes the enterprise bean’s method while the client is not associated with a transaction context, the container automatically starts a new transaction before delegating a method call to the enterprise bean business method. The container automatically enlists all the resource managers accessed by the business method with the transaction. If the business method invokes other enterprise beans, the container passes the transaction context with the invocation. The container attempts to commit the transaction when the business method has completed. The container performs the commit protocol before the method result is sent to the client.

13.6.2.3 SUPPORTS

The container invokes an enterprise bean method whose transaction attribute is set to SUPPORTS as follows.

  • If the client calls with a transaction context, the container performs the same steps as described in the REQUIRED case.
  • If the client calls without a transaction context, the container performs the same steps as described in the NOT_SUPPORTED case.
  • The SUPPORTS transaction attribute must be used with caution. This is because of the different transactional semantics provided by the two possible modes of execution. Only the enterprise beans that will execute correctly in both modes should use the SUPPORTS transaction attribute.

    13.6.2.4 REQUIRES_NEW

    The container must invoke an enterprise bean method whose transaction attribute is set to REQUIRES_NEW with a new transaction context.

    If the client invokes the enterprise bean’s method while the client is not associated with a transaction context, the container automatically starts a new transaction before delegating a method call to the enterprise bean business method. The container automatically enlists all the resource managers accessed by the business method with the transaction. If the business method invokes other enterprise beans, the container passes the transaction context with the invocation. The container attempts to commit the transaction when the business method has completed. The container performs the commit protocol before the method result is sent to the client.

    If a client calls with a transaction context, the container suspends the association of the transaction context with the current thread before starting the new transaction and invoking the business method. The container resumes the suspended transaction association after the business method and the new transaction have been completed.

    13.6.2.5 MANDATORY

    The container must invoke an enterprise bean method whose transaction attribute is set to MANDATORY in a client’s transaction context. The client is required to call with a transaction context.

  • If the client calls with a transaction context, the container performs the same steps as described in the REQUIRED case.
  • If the client calls without a transaction context, the container throws the javax.ejb.EJBTransactionRequiredException[69]. If the EJB 2.1 client view is used, the container throws the javax.transaction.TransactionRequiredException exception if the client is a remote client, or the javax.ejb.TransactionRequiredLocalException if the client is a local client.
  • 13.6.2.6 NEVER

    The container invokes an enterprise bean method whose transaction attribute is set to NEVER without a transaction context defined by the EJB specification. The client is required to call without a transaction context.

  • If the client calls with a transaction context, the container throws the javax.ejb.EJBException[ 70]. If the EJB 2.1 client view is used, the container throws the java.rmi.RemoteException exception if the client is a remote client, or the javax.ejb.EJBException if the client is a local client.
  • If the client calls without a transaction context, the container performs the same steps as described in the NOT_SUPPORTED case.
  • client inactivity timeout

    WebSphere Application Server

    http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-dist&topic=Transaction_service
    Specifies the maximum duration, in seconds, between transactional requests from a remote client. Any period of client inactivity that exceeds this timeout results in the transaction being rolled back in this application server.

    If you set this value to 0, there is no timeout limit.

    Data type | Integer
    Units     | Seconds
    Default   | 60
    Range     | 0 to 2147483647
    

    http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-dist&topic=tjta_settlog
    The number of seconds after which a client is considered inactive and the transaction service ends any transactions associated with that client. A value of 0 (zero) indicates that there is no timeout limit.

    http://www-01.ibm.com/support/docview.wss?uid=swg1PK07143
    Given the following topology:

       Server 1             Server 2
        EJB 1                EJB 2
    

    If EJB 1 makes a call to EJB 2, and EJB 2 returns correctly, but the transaction on EJB 1 lasts long enough to cause a client inactivity timeout on Server 2, Server 1 will not know until its transaction is finished running. If the transaction lasts a long time, the EJB on Server 1 could potentially run for 30 minutes or more and not realize it will have to perform a rollback, because of the client inactivity timeout.

    The operation is working as designed, but Server 1 should have some way of knowing that it will have to perform a rollback before it spends 30 minutes doing work that will just get rolled back anyway. Currently it cannot know.

    Local fix

    There are two options:

    1. Set the client inactivity timeout to a value long enough to avoid causing the rollback in the first place.

    2. Use an intermediary EJB on Server 1 that uses TX_REQUIRES_NEW or TX_NOT_SUPPORTED before it then forwards the request to Server 2. In this way, the transaction on Server 1 will be suspended before the client call to Server 2. When the transaction on Server 1 resumes, it will not care about keeping Server 2 in the loop and the timeout won’t occur because Server2 was never made a part of Server 1’s transaction.

    _____________________________________________________________________
    server1 client inactivity timeout is set to 60 secs
    server1 Total transaction lifetime timeout 120 secs

    server2 client inactivity timeout is set to 90 secs
    server2 Total transaction lifetime timeout 120 secs

    ejb1 deployed on server1
    ejb2 deployed on server2

    if ejb1 calls ejb2 (method ejb2_m1) and after the call ejb1 keep doing something else for more then 90 secs (server2 client inactivity timeout) and doesnt call anyother methods (including ejb2_m1) on ejb2 then ejb2 will detect client inacticity and rollback the transaction after 90 secs of completion of last call.

    so what the point of ‘client inactivity timeout’ and why it needed when ‘Total transaction lifetime timeout’ is there why not make it default 0.
    _____________________________________________________________________

    ****************************************************
    Total transaction lifetime timeout
    ****************************************************
    The default maximum time, in seconds, allowed for a transaction that is started on this server before the transaction service initiates timeout completion. Any transaction that does not begin completion processing before this timeout occurs is rolled back.

    ****************************************************
    Maximum transaction timeout
    ****************************************************
    Specifies, in seconds, the upper limit of the transaction timeout for transactions that run in this server. This value should be greater than or equal to the value specified for the total transaction timeout.

    This timeout constrains the upper limit of all other transaction timeouts. The following table shows how the different timeout settings apply to transactions running in the server.

    Transaction timeout settings.
    Timeout setting                    | Transactions affected
    -----------------------------------------------------------
    Maximum transaction timeout        | All transactions running in this server that are not affected by the total transaction lifetime timeout or an application component timeout. These transactions include transactions imported from outside this server, such as those imported from a client.
    Total transaction lifetime timeout | All transactions that originated in this server that are not affected by an application component timeout, in other words, the associated application component does not set its own timeout.
    Application component timeout      | Transactions that are specific to an application component. If the component is a container-managed bean, set this timeout in the deployment descriptor for the component. If the component is a bean-managed bean, set this timeout programmatically using the UserTransaction.setTransactionTimeout method.
    

    If you set a timeout to 0, that timeout does not apply, and is effectively disabled. If you set all timeouts to 0, transactions never time out.

    For example, consider the following timeout values:

    Maximum transaction timeout        360
    Total transaction lifetime timeout 240
    Application component timeout       60
    

    In this example, transactions that are specific to the application component time out after 60 seconds. Other local transactions time out after 240 seconds, and any transactions that are imported from outside this server time out after 360 seconds. If you then change the application component timeout to 500, application component transactions time out after 360 seconds, the value of the maximum transaction timeout. If you set the maximum transaction timeout to 0, application component transactions time out after 500 seconds. If you remove the application component timeout, application component transactions time out after 240 seconds.
    To determine the occurrence of a timeout quickly, and to prevent further resource locking, the application server prevents further transactional work on the transactional path where the timeout condition has taken place. This applies equally to attempting to perform work under the current transaction context and to attempting to perform work under a different transactional context.

    Data type | Integer
    -------------------
    Units     | Seconds
    Default   | 300
    Range     | 0 to 2 147 483 647
    Range     | 0 to 2 147 040
    

    Weak Reference

    Weak Reference holds reference to an object (referent)

    public Map<Task, TaskStatus> taskStatus
        = Collections.synchronizedMap(new HashMap<Task, TaskStatus>());
    

    if only out standing reference to referent are weak then referent becomes candidate for GC

    WeakReference.get returns the referent
    it can return null because
    1- WeakReference.clear is called, or
    2- refrent is garbage collected because it has no reachable strong references.

    always check for null to get referent from WeakReference.get

    WeakHashMap uses weak reference for __keys__ (not for values)

    so an entry stays in the WeakHashMap as long as there is a reachable strong reference to __key__
    and only after that “strong reference” to __value__ will released.

    life time of __value__ is under the control of (with other things) the outstanding strong reference to __key__ in weakhashmap

    When WeakReference.get() is called, it returns a strong reference to the referent (if it is still alive), so there is no need to worry about the mapping disappearing in the body of the while loop because the strong reference keeps it from being garbage collected.

    When you add a mapping to a WeakHashMap, remember that it is possible that the mapping could “fall out” later because the key is garbage collected. In that case, get() returns null, making it even more important than usual to test the return value of get() for null.

    Map<Socket,User> m = new WeakHashMap<Socket,User>();
    

    here life time of User object is controlled by lifetime of Socket object (if this map is the only one hold any outstanding strong reference to User) since __key__ is weak referenced, User object will become gc’able as soon as (its key) Socket object becomes gc’able.

    gc’able – no reachable strong reference exists.

    ==============
    Reference Queue
    ==============
    something must also be done to prune the dead entries from the Map after the key object has been collected. Otherwise, the Map would simply fill up with entries corresponding to dead keys. it could still cause the application to run out of memory because the Map.Entry and value objects would not be collected, even if the key is.

    Dead mappings could be eliminated by periodically scanning the Map, calling get() on each weak reference, and removing the mapping if get() returns null. But this would be inefficient if the Map has many live entries. It would be nice if there was a way to be notified when the referent of a weak reference is garbage collected, and that is what reference queues are for.

    Reference queues are the garbage collector’s primary means of feeding back information to the application about object life cycle.

    WeakReference has 2 Constructors

        
        WeakReference(T referent) 
                  // Creates a new weak reference that refers to the given object.
        
        WeakReference(T referent, ReferenceQueue<? super T> q) 
                  // Creates a new weak reference that refers to the given object and is registered with the given queue.
    

    How does GC notify that referent in a WeakRefernce object has become candidate for GC?

    lets say WeakReference object was created with the second constructor, that takes ReferenceQueue as argument.
    When referent becomes candidate for GC the “WeakReference object” (not referent) will be added (enqueue) to ReferenceQueue queue.
    so by polling on ReferenceQueue application can find out what “WeakReference object”‘s referent has become candidate for GC and do the appropriate clean up, like remove entry for that “WeakReference object” from WeakRefrenceMap (remember __key__ in WeakRefrenceMap is weak)
    RefrenceQueue offer following dequeuing —
    polled, timed blocking, and untimed blocking.
    All Reference types are cleared before they are enqueued, so the thread handling the post-mortem cleanup never has access to the referent object, only the Reference object.

    WeakHashMap has a private method called expungeStaleEntries() that is called during most Map operations, which polls the reference queue for any expired references and removes the associated mappings.

    WeakHashMap.get method returns “strong reference” to the referent, so we dont have to worry if reference will become invalid after we got from WeakHashMap.

    =====================================
    Soft Reference
    =====================================
    If the only remaining references to an object are weak or soft references, then that object is said to be softly reachable.

    Soft references are a way of saying to the garbage collector, “As long as memory isn’t too tight, I’d like to keep this object around. But if memory gets really tight, go ahead and collect it and I’ll deal with that.”. The garbage collector is required to clear all soft references before it can throw OutOfMemoryError. The key to whether a soft reference can be used is whether an application can recover from the loss of the data being cached.

    If you need to cache more than a single object, you might use a Map, but you have a choice as to how to employ soft references. You could manage the cache
    as a
    Map<K, SoftReference>
    or as a
    SoftReference<Map>.

    The latter option is usually preferable, as it makes less work for the collector and allows the entire cache to be reclaimed with less effort when memory is in high demand.

    Weak references are sometimes mistakenly used instead of soft references for building caches, but this will result in poor caching performance. In practice, weak references will get cleared fairly quickly after the object becomes weakly reachable — usually before the cached object is needed again — as minor garbage collections run frequently.

    Reference queues are not as useful with soft references as with weak references, but they could be used to raise a management alert that the application is starting to run low on memory.

    clone is not copy constructor

    what does Cloneable do? Its a marker interface that has no methods and implementing class is saying that if you call a clone method and in the super.clone chain it ends up calling clone method of Object class it’ll no throw CloneNotSupportedException, and return field-by-field (shallow) copy of the object. Most important thing is the object return by Object.clone is __not__ created by constructor (and may be that’s why its a native method in Object class) so all the invariants constructor forces to ensure validity of the object will not be applied.

    ****** ****** ******
    Object.clone will return shallow copy of the object in its __current__ state if the Class of the object this method has been called on implements Cloneable interface otherwise it throws CloneNotSupportedException
    ****** ****** ******

    Cloneable is an interface that defines the behaviour of a protected method (clone) of a class (Object), very innovative use of an interface, isn’t it.

    if object is immutable there is __no__ need to clone it, because cloned instance is indistinguishable from original instance. If object is mutable “shallow copy” might be a big mistake. Then what’s the point Cloneable is trying to make?

    And if a class implement Cloneable interface and implement clone method to support __deep__ copy, it can not reassign final fields because clone method is not constructor, implies if you want to deep copy a final field in clone method you can not do that and make it non-final.

    2 solutions suggested by Mr Bloch in item 11–
    1. Factory method

    public static Yum newInstance(Yum yum)

    2. Copy constructor

    public Yum(Yum yum)

    http://www.artima.com/intv/bloch14.html

    Websphere class loaders

    1. Bootstrap
      • jre/lib
      • jre/lib/ext
      • CLASSPATH environment variable
    2. Extension
      • ws.ext.dirs system property to determine the path that is used to load classes.
    3. Application module classloaders
      • shared libraries
    4. Web module classloaders
      • WEB-INF/classes
      • WEB-INF/lib

    lifetime of a finalizable object obj

    lifetime of a finalizable object obj

    1. When obj is allocated, the JVM internally records that obj is finalizable. This typically slows down the otherwise fast allocation path that modern JVMs have.
    2. When the garbage collector determines that obj is unreachable, it notices that obj is finalizable — as it had been recorded upon allocation — and adds it to the JVM’s finalization queue. It also ensures that all objects reachable from obj are retained, even if they are otherwise unreachable, as they might be accessed by the finalizer.
    3. At some point later (only gc knows when), the JVM’s finalizer thread will dequeue obj, call its finalize() method, and record that the obj’s finalizer has been called. At this point, obj is considered to be finalized.
    4. When the garbage collector rediscovers that obj is unreachable, it will reclaim its space along with everything reachable from it, provided that the latter is otherwise unreachable.

    garbage collector needs a minimum of two cycles to reclaim obj and needs to retain all other objects reachable from obj during this process.

    Additionally, the JVM does not guarantee that it will call the finalizers of all the finalizable objects that have been allocated. It might exit before the garbage collector discovers some of them to be unreachable.