Rules of Serialization

Here is a summary of some rules of Java serialization:

• An object is serializable only if its class or its superclass implements the Serializable (or Externalizable) interface.
• An object is serializable (itself implements the Serializable interface) even if its superclass is not. However, the first superclass in the hierarchy of the serializable class, that does not implements Serializable interface, MUST have a no-arg constructor. If this is violated, readObject() will produce a java.io.InvalidClassException in runtime.
• The no-arg contructor of every non-serializable superclass will run when an object is deserialized. However, the deserialized objects? constructor does not run when it is deserialized.
• The class must be visible at the point of serialization.
• All primitive types are serializable.
• Transient fields (with transient modifier) are NOT serialized, (i.e., not saved or restored). A class that implements Serializable must mark transient fields of classes that do not support serialization (e.g., a file stream).
• Static fields (with static modifier) are Not serialized.
• If member vairiables of a serializable object reference to a non-serializable object, the code will compile but a RumtimeException will be thrown.

EJB 2 vs EJB3

1) The deployment descriptors are no longer required; everything can be accomplished using metadata annotations.

2) The CMP has been simplified; it is now more like Hibernate or JDO.

3) Programmatic defaults have been incorporated. For example, the transaction model is set to REQUIRED by default. The value needs to be set only if a specific value other than the default value is desired.

4) The use of checked exceptions is reduced; the RemoteException is no longer mandatory on each remote business method.

5) Inheritance is now allowed; therefore, beans can extend some of the base code.

6) The native SQL queries are supported as an EJB-QL (Query Language) enhancement.

weblogic training 3

1) Jrocket jvm is better for intel platform.

2) Sun jdk is better for sun servers.

3) JMS server is engine which stores messages.

4) JMS module will have resources

Deploy a Queue to JMSServer is called subdeokoyment

5) Create jdbc resource.

SNMP

C:\devtools\bea10mp1\user_projects\domains>cd jms_domain

C:\devtools\bea10mp1\user_projects\domains\jms_domain>cd bin

C:\devtools\bea10mp1\user_projects\domains\jms_domain\bin>setDomainEnv.cmd

C:\devtools\bea10mp1\user_projects\domains\jms_domain>java snmptrap

Exception in thread "Main Thread" java.lang.NoClassDefFoundError: snmptrap

C:\devtools\bea10mp1\user_projects\domains\jms_domain>java snmptrapd

WorkManager--

Requestclass

1) Fair Share

2) Response time

3) User Context.

C:\devtools\bea10mp1\user_projects\domains>cd jms_domain

C:\devtools\bea10mp1\user_projects\domains\jms_domain>cd bin

C:\devtools\bea10mp1\user_projects\domains\jms_domain\bin>setDomainEnv.cmd

C:\devtools\bea10mp1\user_projects\domains\jms_domain>java weblogic.Admin -adminurl "t3://localhost:

7001" -username weblogic -password weblogic THREAD_DUMP

Thread Dump has been printed to the servers standard out (by default, the shell in which the server

is running).

C:\devtools\bea10mp1\user_projects\domains\jms_domain>

Server is in standby mode.

use different port.

click the resume mode.

See the status as admin -- from RUnning

JMS make them migratable/ JTS make them migratable.

Cluster domain

Migration - automatic.

Configuration- Migration - automatic

WLST command to take the backup

java weblogic.WLST

help('configToScript');

configToScript('.../jmsdemo','d:/scropts');

papa_rao@hotmail.com

93413 03004

weblogic clustering

1) Database level failover clustering.

2) Application level load balancing clustering.

3) admin server will not be part of the cluster.

4) Cluster can not span domains.

5) Domain and below are clusters.

6) http clustering DNS round robin, Proxy server, Hard ware

7) DNS will not work if port number are different.

8) Production server does not use DNS round robin.

9) Proxy server on client is called proxy.

10) Proxy on server is called reverse proxy.

11) Proxy's problem is round robin algorithm.

12) People mostly use Hardware servers.

13) Big IP, IBM edge load balancer.

14) Replication groups for http sessions.

15) Replication group can have the limit of 2.

16) Clustering does not have any limits.

17) Persistent session-J2ee concept.

18) web.xml specify storage-type persistent and jdbc parameter.

19) Heartbeats called mulitcasting.

20) TCP have following types communication. Unicasting 1-1, Broad casting 1-all, Mulitcasting 1- many.

21) One adapter for internal and one adapter for external. Use access and mutlicast address.

22) Class D is dedicated to multicasting.....

23) end with 255

24) Class A, B, C is for unicasting.

1-126 class A

127 look back

128 -191 class B

192 - 223 class C

224 - 239 class D

25) Heart beats and JNDI updates (mulitcasting are required)

26) create server ---> Create Proxy ---> Assign server to cluster

27) Start Node manager.

28) Start clusters.

29) C:\devtools\bea10mp1user_projects\domains\cluster_demo_domain\bin>startManagedWebLogic.cmd Mem2 http://localhost:7001

30) PersistantStoreType parameter weblogic.xml param value replicated. (Replica aware).

31) Change it to jdbc.

32) Use both inmemory + persistent store.

33) JMS Server in a singleton. JMS Server -- target weblogic instance 1. Create them as migratable target. JDBC

-Order of loading classes.

1. Kernel

2. JDBC

3. JMS (System resources.)

4. jars

5. wars

6. startup classes.

7.applications.

Startupclasses

weblogic training

1. TO create domain C:\devtools\bea10mp1\wlserver_10.0\common\bin>config.cmd
2. Security service provide api
3. Three security model basic, form, digest and
4. open ldap
5. volatile data store in the DB. non-volatile data store in ldap.
6. Roles does not come under weblogic administrator.
7. Security has algorithms. More permission are allowed. If denied, It will take precedence.
8. group level is precendence over user level.
9. Never assign permissions to the users.
10. Roles can be changed through admin console for quick fixes but not reliable as next build it will be lost. you need to have process to take care of it.
11. IpSec is used by VPN. IT is 2-way authentication. Encryption will be there.
12. weblogic replication is for localization of data. like manufacturing of data.
13. Failover and FailBack. Failback where primary becomes primary again.
14. Oracle mirroring is cheapest solution.
15. Log chaipping and configuring the mirror.
16. Multi Data Source are required because fail back server would have different instance names. Only clustering this is not required because of virtual address.
17. Mirroring also required multi data source because of same reason.
18. Create domain using config.cmd.
19. For trusted domains.
C:\devtools\bea10mp1\wlserver_10.0\common\nodemanager\nodemanager.domains
medrec=C\:\\devtools\\bea10mp1\\wlserver_10.0\\samples\\domains\\medrec
20. bea\wlserver\server\bin\startNodeManager.cmd apurang1 5556
21. Node Manager only starts the managed server. After that it is direct communication.
22. java weblogic.WLST to start wlst
C:\devtools\bea10mp1\wlserver_10.0\server\bin\
installNodeMgrSvc.cmd

installSvc.cmd command

Interview-java-

http://www.javaperformancetuning.com/tips/appservers.shtml#REF9

Class Loader

Typically class loaders are arranged in a parent/child hierarchy. When a class loading request is presented to a class loader, it first asks its parent class loader to fulfill the request. The parent, in turn, asks its parent for the class until the request reaches the top of the hierarchy. If the class loader at the top of the hierarchy cannot fulfill the request, then the child class loader that called it is responsible for loading the class. If the child is also unable to load the class, the request continues back down the hierarchy until a class loader fulfills it or aClassNotFoundException is produced by the class loader at the bottom of the hierarchy.

Figure 1 illustrates a basic class loading hierarchy. Note that a class loaded at a given level in the hierarchy may not reference any classes loaded at a lower level in the hierarchy. Stated another way, a class loader has no visibility into classes loaded by its descendants. In figure 1, if class Foo is loaded by class loader B, and Foodepends on class Baz, then class Baz must be loadable by either class loader A or B. If Baz is only visible to class loader C or D, then a ClassNotFoundException will occur.

ArrayList

Now for some implementation notes. The ArrayList is actually encapsulating an actualy Array, an Object[]. When you instanciate ArrayList, an array is created, and when you add values into it, the array changes its size accordingly. This gives you strengths and weaknesses:

• Fast Random Access

You can perform random access without fearing for performence. Calling get(int) will just access the underlying array.

• Adding values might be slow When you don’t know the amount of values the array will contain when you create it, a lot of shifting is going to be done in the memory space when the ArrayList manipulates its internal array.
• Slow manipulation When you’ll want to add a value randomly inside the array, between two already existing values, the array will have to start moving all the values one spot to the right in order to let that happen.

LinkedList

The LinkedList is implemented using nodes linked to each other. Each node contains aprevious node link, next node link, and value, which contains the actual data. When new data is inserted, a node is inserted and the links of the surrounding nodes are updated accordingly. When one is removed, the same happens – The surrounding nodes are changing their links and the deleted node is garbage collected. This, as well, gives strengths and weaknesses:

• Fast manipulation As you’d expect, adding and removing new data anywhere in the list is instantanious. Change two links, and you have a new value anywhere you want it.
• No random access Even though the get(int) is still there, it now just iterates the list until it reaches the index you specified. It has some optimizations in order to do that, but that’s basically it.

Some Conclusions

ArrayList is very useful when a well defined set of data is needed in a List interface as opposed to an array. It can be dynamically changed, but try not to do so frequently throughout the life of the application. LinkedList is there for you to do just that:Manipulating it is very easy, and as long as its used for iteration purposes only and not for random accessing, it’s the best solution. Further, if you need random accessing from time to time, I suggest toArray for that specific moment.

Another point I didn’t raise here is the Queue issue. LinkedList implements extended abilities to the normal List interface which allows it to add and remove elements from its beginning and end. This makes the LinkedList perfect for Queue and Stack purposes – Although in Java 5 they already added a Stack class.

Hope this helped someone. Tell me if you want to differ.

SoftReferences are typically used for implementing memory caching. The JVM should try to keep softly referenced objects in memory as long as possible, and when memory is low clear the oldest soft references first. According to the JavaDoc, there are no guarantees though.

WeakReferences is the reference type I use most frequently. It's typically used when you want weak listeners or if you want to connect additional information to an object (using WeakHashMap for example). Very useful stuff when you want to reduce class coupling.

Phantom references can be used to perform pre-garbage collection actions such as freeing resources. Instead, people usually use the finalize() method for this which is not a good idea. Finalizers have a horrible impact on the performance of the garbage collector and can break data integrity of your application if you're not very careful since the "finalizer" is invoked in a random thread, at a random time.

In the constructor of a phantom reference, you specify a ReferenceQueue where the phantom references are enqueued once the referenced objects becomes "phantom reachable". Phantom reachable means unreachable other than through the phantom reference. The initially confusing thing is that although the phantom reference continues to hold the referenced object in a private field (unlike soft or weak references), its getReference() method always returns null. This is so that you cannot make the object strongly reachable again.

From time to time, you can poll the ReferenceQueue and check if there are any new PhantomReferences whose referenced objects have become phantom reachable. In order to be able to to anything useful, one can for example derive a class from java.lang.ref.PhantomReference that references resources that should be freed before garbage collection. The referenced object is only garbage collected once the phantom reference becomes unreachable itself.

• Performance
• How quickly must the system respond to interactive operations of different kinds?
• Are there different classes of interactive operations that users have different tolerances / expectations for?
• Is there a batch window? What runs in it?
• Do the batches have their own performance constraints, e.g., to clear the batch window before it closes?
• Does the batch load influence any interactive users running at the same time?
• Is there data with a high read/write access ratio that can be cached in memory at different tiers in the architecture?
• What are the expected performance bottlenecks?
• CPU?
• Memory on client, server or intermediate nodes?
• Hard drive space on each node?
• Communications links?
• DB
• Access
• Searching
• Complex joins
• Interaction with other internal systems?
• Interaction with systems in other departments?
• Interaction with partner systems?
• Interactions with public systems?
• Scalability
• Peak load of how many users doing what kinds of operations?
• Ability to grow to how many records in which critical database tables without slowing down related operations by more than X
• Avoiding saturating a communication link that cannot be upgraded to a higher speed?
• What dimensions can be scaled, e.g., more CPUs, more memory, more servers, geographical distribution?
• Is the primary scaling strategy to "scale up" or to "scale out" -- that is, to upgrade the nodes in a fixed topology, or to add nodes?
• Availability
• What is the required uptime percentage?
• Does this vary by time of day or location?
• What is the current schedule of controlled outages? Is this acceptable, or is there a goal to improve it?
• Reliability
• Are there components with reliabilities that are known to be less than the required reliability of the system?
• What strategies are currently in place to build more reliable capabilities out of less reliable capabilities?
• What is the expected mean time to failure by failure severity by operation?
• How will reliability be assessed prior to deployment?
• Security
• What operations need to be secured?
• How will users be administered?
• How will users be given permissions to access secured operations?
• What are the different levels of security and how do these map
• Security by operation
• Security by type of object
• Security by instance of object
• Maintainability
• Are there concerns about the ability to hire appropriate technology skills, attract them to the area at reasonable prices?
• What kinds of changes are anticipated in the first rounds of maintenance? What are their relative priority?
• What sort of regression testing is required to ensure that maintenance changes do not degrade existing functionality?
• What sort of maintenance documentation is expected to be produced? When?
• Flexibility
• Is there system behavior that needs to be changed regularly without program changes?
• Can this be encoded in the database?
• Are there run-time rules that can be handled using a rules interpretation engine?
• Are there functions that should be user scripted? If so, how will these be QA-ed?
• Configurability
• What parameters need to be set on a machine-by-machine basis?
• Personalizability
• What aspects of the system can be customized on a per-user basis?
• How does the user change these settings?
• What is the strategy for defaults?
• Usability
• Are there operations that need to be done as quickly as possible, so that user gestures should be minimized?>
• Are there difficult or occasional-user operations that require non-standard presentations to help the user perform correctly?
• What is the balance between data integrity and the ability to stop in a "work in progress" state?
• What styles of validation are used in what situations?
• What metaphors from existing or parallel systems should be used?
• What sort of training deliverables are expected?
• What sort of on-board help system is expected?
• Portability
• Data portability between this system and other systems?
• Portability across different versions of a single vendor's DB?
• Ability to port to a different vendor's DB? Which one(s)? When?
• Browser portability? What browser versions? Historical and future?
• Operating system portability?
• Conformance to standards
• What legal standards apply?
• What technical standards apply?
• Other standards, e.g., 508.1 for disabled users?
• What development standards apply?
• Database naming standards
• Existing internal architectural standards (e.g., everything goes in an Oracle database)
• Language and coding standards
• Testing and review standards
• Presentation standards, e.g., use of standard colors, controls or other affordances?
• Lifecycle models or methodologies
• Internationalizability
• What languages?
• In what order?
• How translated?
• Single or multi byte character sets?
• Efficiency -- space and time
• Responsiveness
• What are the expected and upper limit response times per operation in the system?
• What is the trade-off between lower averages and wider variations in response time?
• Interoperability
• What systems will this system interoperate with immediately?
• What other systems are anticpated?
• What classes of internal and external systems might later be needed to interoperate with?
• What functionality from this system needs to be exposed as a service in a service oriented architecture?
• What functionality from this system needs to be exposed as a Web service or via a portal?
• Upgradeability
• Do the servers need to be upgraded while running?
• How many client stations need to be upgraded, and what are the costs and mechanisms for upgrading them?
• How often do different kind of fixes need to be distributed? Are there "hot fixes" that have to go out right away, but others that can wait? How often do each kind occur?
• Auditability / traceability
• What record of who did what when must be maintained?
• For how long?
• Who accesses the audit trails?
• How?
• Is archive to tape or other off-site storage media required?
• Is "effective dating" required?
• Transactionality
• What are the important database and application transaction boundaries?
• Is standard "optimistic" locking appropriate, or is something more complex required in some or all cases>
• Is disconnected operation required by any node?
• Administrability
• What live usage information needs to be displayed?
• To who? How? When?
• What "live" interventions are required?
• What ability to handle remote configurations are required?
• Are there existing application management consoles that will be used to manage this application?
• Lots of others -- what are your favorites?

Usefull links

Architecture

http://www.softwarearchitecturenotes.com/architectureRequirements.html