YUI study notes - Event

The window.onload event is synchronous with images and external dependencies, so it doesn't fire until they've all resolved (or timed out), also in some browser (IE), the target elements that do not yet exist when onload event fired. What we really want is an event that fires when the DOM ready, YUI's onDOMReady(), onAvailable() and onContentReady () help to avoid this problem.

Event object is accessed differently in different browser. In IE the event object is accessed through the window object, whereas in Firefox, it is automatically passed to your event handler as an argument.

[1] has a good explanation on the callback function signature.

Callback for Native Browser Events

var callback = function(e, o) {
  alert(o.msg);
}; 

YAHOO.util.Event.addListener(elemId, "click", callback, {msg: "hi"}); 

Callback for Custom Events
If the custom event is fired with parameter signature YAHOO.util.CustomEvent.LIST, which is by default

var callback = function(e, a, o) {
  //a is an array contains arguments fire method: arg1, arg2, ...
  //o is the object passed from the subscribe method
  alert(o.msg);
};

//to fire this event
eventObj.fire(arg1, arg2, ...);

//to listen to this event
eventObj.subscribe(callback, {msg: "hi"});

where
e - Name of this custom event.
a - Arguments that passed to the fire method of this event.
o - Object that passed as a parameter to this callback function.

If the custom event is fired with parameter signature YAHOO.util.CustomEvent.FLAT

var callback = function(a, o) {
  //a is the first argument that passed to fire method of this event
 //o is the object passed from the subscribe method
  alert(o.msg);
};

//to fire this event
eventObj.fire(arg);

//to listen to this event
eventObj.subscribe(callback, {msg: "hi"});

Redirect-after-Post pattern and Session bound ActionMessages

To deal with double submit problem, the Redirect after Post pattern is purposed in [1] and [2].
- Never show pages in response to POST
- Always load pages using GET
- Navigate from POST to GET using REDIRECT

To facilitate this, the errors/messages need to be stored in session scope, o/w they would get lost after redirect. From Struts 1.2.4, Action.saveMessages(HttpSession, ActionMessages) is added [3]. Upon the first access to the messages they are effectively removed from the session. This allows messages to be retained when using the redirect after post pattern.

ActionRedirect inherits from ActionForward, with support for adding parameters at runtime.

MySql straight join and index hint

SELECT STRAIGHT_JOIN p.NAME AS NAME,
    ROUND(AVG(r.VAL)) AS AVGVAL,
    MIN(r.MINVALUE) AS MINVAL,MAX(r.MAXVALUE) AS MAXVAL
FROM reports_hourly AS r force index (PRIMARY), polleddata AS p,wirelessaccesspoint ap
WHERE p.OID = ? AND p.ID=r.POLLID
  AND r.ttime >= ? AND p.name=ap.name AND ap.aprole=0
GROUP BY p.NAME
ORDER BY AVGVAL DESC
LIMIT 0,5

* Table reports_hourly is the biggest table, contains millions records. Its primary key index is on (ttime, pollid). If move it to the last table to join, the query would run much slower.

MySql innodb transaction/logs

- MySql's innodb follows Oracle's multi-version read consistency model. It's multi version is based on undo log. In Innodb, each table has two hidden columns, a transaction number and a pointer to the previous version of that row in the undo log. With the rollback pointer, READ COMMITTED can go back one step to the past, whereas REPEATABLE READ can go back multiple steps until it reaches the newest version after its transaction starts. Based on the transaction number, we know particular row in data buffer is associated with committed or uncommitted transaction.

- Write-Ahead logging (WAL) principal: all modifications are written to a log before they are applied to the database. It is to guarantee the Atomicity and Durability of ACID. WAL significantly reduces the number of disk writes, since only the log file needs to be flushed to disk at the time of transaction commit. In multi-user environments, commits of many transactions may be accomplished with a single fsync() of the log file. The log file is written sequentially, so the cost of syncing the log is much less than the cost of flushing the data pages. Writing back change to table space involves slow disk seek rather than liner write. Another benefit of WAL is consistency of the data pages.

- Two buffers: log buffer and data buffer in InnoDb. Log buffer is for insert/update, whereas data buffer is for all operations, it used to cache data and indexes of the tables. Also there are some other memory buffer such as sort buffer and query cache buffer. When a transaction commit, the rows in log buffer are flushed to disk, whereas the rows in data buffer are marked as dirty but not flushed. When innodb_flush_log_at_trx_time set to 0, even the log buffer is not flushed (not recommended). There are several threads monitoring buffer activity, and three situations -- overflow, checkpoint, and commit -- that result in disk writes.

- InnoDB uses both row level locking and multi-versioning concurrency control (MVCC). Multi-version Consistent read is the default mode in which InnoDB processes SELECT statements in READ COMMITTED and REPEATABLE READ isolation levels. FOR UPDATE or IN SHARE MODE apply exclusive (X) lock and shared (S) lock.

- Checkpoint: InnoDB takes some pro-active measures against overflows, and the most important of these measures is checkpointing. There is a separate thread, or a combination of threads that are separate from the thread that changes the buffers. At fixed intervals the checkpointer will wake, look for buffer changes, and ensure that writes happen.

See:
Transactions - An InnoDB tutorial
How Logs work on MySQL with InnoDB tables