The Spring Container Lifecycle

The Spring Container Lifecycle

When you mount an application context, Spring starts up, following a predictable lifecycle. The actions it performs are:

1. Load all bean definitions before constructing beans
2. Construct each bean via reflection
3. Inject components via setters, autowired methods, etc...
4. Post-process the bean
5. Make the bean available for use by injection or direct lookup

Obviously we're going to focus on that post-processing step. It turns out Post Processing allows Spring's magic to happen.


http://java.dzone.com/articles/spring-corner-what-are-those?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+%28Javalobby+%2F+Java+Zone%29

CompletionService

Omitting many many details:

• ExecutorService = incoming queue + worker threads
• CompletionService - incoming queue + worker threads + output queue

A service that decouples the production of new asynchronous tasks from the consumption of the results of completed tasks. Producers submit tasks for execution. Consumers take completed tasks and process their results in the order they complete. A CompletionService can for example be used to manage asynchronous IO, in which tasks that perform reads are submitted in one part of a program or system, and then acted upon in a different part of the program when the reads complete, possibly in a different order than they were requested.  --- From CompletionService Javadoc.

Synchronized methods vs Synchronized block

Synchronized method :

JVM (built into JVM)

• automatically acquires object's lock 
• calls the method
• releases the lock

If an exception occurs thread automatically releases the lock

http://stackoverflow.com/questions/574240/synchronized-block-vs-synchronized-method

sql: self-joins explained - Stack Overflow

sql: self-joins explained - Stack Overflow

Coding Horror: A Visual Explanation of SQL Joins

Coding Horror: A Visual Explanation of SQL Joins

Indexes

• Clustered indexes can randomize data inserts, avoiding insert “hot spots” on the last page of a table.
• Indexes can help avoid sorts, if the index order matches the order of columns in an order by clause.

In addition to their performance benefits, indexes can enforce the uniqueness of data.

A table that has no clustered index is called a heap. The rows in the table are in no particular order, and all new rows are added to the end of the table.

Sybase Locking schemes

Less overall work is required to use a table-level lock, but large-scale locks can degrade performance, by making other users wait until locks are released. Decreasing the lock size makes more of the data accessible to other users. However, finer granularity locks can also degrade performance, since more work is necessary to maintain and coordinate the increased number of locks. To achieve optimum performance, a locking scheme must balance the needs of concurrency and overhead.

Adaptive Server provides these locking schemes:

• Allpages locking, which locks datapages and index pages
  In many cases, the concurrency problems that result from allpages locking arise from the index page locks, rather than the locks on the data pages themselves. Data pages have longer rows than indexes, and often have a small number of rows per page. If index keys are short, an index page can store between 100 and 200 keys. An exclusive lock on an index page can block other users who need to access any of the rows referenced by the index page, a far greater number of rows than on a locked data page.
• Datapages locking, which locks only the data pages
  
  
• Datarows locking, which locks only the data rows