# English

## IE may never load "defer"ed javascripts

Today, I found a strange problem that one app on my site disppeared when viewed with IE9.  No code error were reported in the debug tools.  I tested downgrading IE9 to IE7/8 modes, but the problem persisted.  However, when testing with other browsers (Firefox, Empiphany, Chrome, Safari), the app worked on all of them.  So I focused debugging on IE.

With the debug tools, I found that a variable that should be assigned if the script runs does not exist.  I started to doubt that the script is not running.  Also I occasionally notice that when I switch debugging tool to script of the app, it could be either a blank or loading to give a view.  Therefore, I locked the phenomenon.  After manipulating the <script ... > code piece a few times, I finally found that if I remove the "defer" attribute from it, the page sucks when loading but the app appears.  But luckily I found an easy way to get around.  Now the problem is fixed.

So, my suggestion is that avoid using a "defer" attribute in the script tag.  Interestingly, if I create a script element using JS, and assign its "defer" property to true, it will not block loading and running of the JS in IE.

<script src="file.js" defer></script>

you are recommended to use:

<script>
  var s=document.createElement('SCRIPT');
  s.src='file.js';
  s.defer=true;
  setTimeout("document.getElementsByTagName('HEAD')[0].appendChild(s)",20);
</script>

or some like it.

## Make Your NFS Session Safe!

When you use several servers to balances loads of a website, it often needs to keep sessions consistent through out accesses of a user.  Often, two methods are adopted.

• One method is to ask the load-balancer to direct all requests of a single session ID to a single server.
• The other method is to share session data among all servers.

The first method works.  But if your web page issues multiple requests to complete its loading, this method will collect burdens to a single server and may elongate the time required that a page completes its loading process.

Now the second method give a solution.  Because several servers can respond to one page concurrently, a page can be expected to have a shorter loading time.  But this may require that all the servers share the same session data, otherwise a user may be confused because he sees an inconsistent page as requests go to different servers.

A transactional database gives a safe solution.  All storage and retrieval of session data are performed atomically.  But this solution is a bit heavy.  A DBMS often needs more memory to run.  And CGI scripts have to build SQL statements with serialized session data, and this process often costs extra memory.  Handshake of database connection also costs additional time.

With NFS, things are quite alleviated.  But many people would argue that NFS does not perform fine grind atomicity, and this could break your data.  This is true.  But there is always a method to get arround.  In the following text I will propose such a method.

Every process that tries to lock "FileA" must create a different link.  The link must be able to uniquely identify a valid locker process.  This can be accomplished by appending a process ID and a machine ID to "FileA.lock".  For example, "FileA.lock.{Proc ID}.{Web Server IP}".  If thread ID is available, it also needs be added.

The simple sketch may look ok, but there is a problem.  How about a process dies before it can release the lock?  All the following locking tries will fail, and your website will be deadlocked.  Therefore the locking algorithm must detect and tackle with the problem.

A solution is to set a locking timeout.  When a file has been locked for too long, it is reasonable to think that the process terminated prematurely, so that someone else should help it to release the lock.  With a timeout, an algorithm can simply delete all locking links that are old enough.  Another thing to notice is that all hard links to a file share the same time information, therefore create file of all links must be stored separately.  The whole algorithm looks like the following:

1. Create a unique name for the hard link and a unique name for the file to save link time.
2. Create a hard link to the target file with the name created in step 1.
3. Get lock time from the hard link.
4. Save time of the hard link to the file determined by 1.
5. If link number of the target file is 2, then go to 6., otherwise:
1. Delete all old enough lock hard links and their time files.
2. Delete current lock hard link.
3. Sleep for a little while.
4. Go to 3.
6. End.

The following PHP code is a real functional example.

function lock_touch_file($filepath,$lock_max_lifesecs=5)

{

	$lockid=getmypid().'_'.$_SERVER['SERVER_ADDR'];

	$lockfilepath=$filepath.'.lock.'.$lockid; $locktimepath=$filepath.'.locktime.'.$lockid;

	if (!file_exists($filepath))  { $filedir=dirname($filepath);  @mkdir($filedir,0755,true);

		if (!@touch($filepath))  return false;  }  @unlink($lockfilepath);

	do {

		link($filepath,$lockfilepath);	// Create the lock

		clearstatcache();

		$curlocktime=filectime($lockfilepath);	// Get lock time

		file_put_contents($locktimepath,$curlocktime);	// Save lock time

		$stat=stat($filepath);

		if ($stat['nlink']!=2)  { $lockfiles=glob($filepath.'.lock.*',GLOB_MARK|GLOB_NOSORT); $pfxlen=strlen($filepath.'.lock.');  foreach ($lockfiles as $lf)  { $lfid=substr($lf,$pfxlen);

				$ltf=$filepath.'.locktime.'.$lfid; $lfctime=@file_get_contents($ltf);  if ($lfctime+$lock_max_lifesecs<$curlocktime)

				{

					@unlink($lf);  @unlink($ltf);

				}

			}

			@unlink($lockfilepath);  @unlink($locktimepath);

			usleep(mt_rand(10,5000));

		}

		else

			break;

	} while (true);

	return true;

}

function unlock_file($filepath) {  unlink($filepath.'.lock.'.getmypid().'_'.$_SERVER['SERVER_ADDR']);  unlink($filepath.'.locktime.'.getmypid().'_'.$_SERVER['SERVER_ADDR']); } Through the algorithm above, it can be guaranteed that no two processes are accessing the target file at the same time during the same safe period($lock_max_lifesecs).  However, this algorithm has a critical weakness which makes it unable to fit busy systems.  Think of that you server is busy, it means that there almost always multiple processes links to the file, no matter how long you wait, link number of the target file is always larger than 2.  It effectively creates a deadlock.  Therefore, only use this algorithm if your target file is not very frequently accessed.

A better technique exists, it will be discussed at a future time.

## Let Freelance Instructors Accept Students' Reservations More Easily

To solve the above problem, Uniwits Online Reservation Service(UORS) is the solution that you want.  Simply speaking, an instructor publish his lectures on the Internet, and students reserve lectures on the Internet.  UORS is the Internet service that connects an instructor and his students.  When a student reserves a lecture, you will be notified by a system message.  When a student changes or cancels a reservation, you will also get notified.  During the process, as an instructor, you don't need any operation.  Just know something about reservation happens and deliver your lecture as reserved.

Next, lets know something more. You may be a language teacher, a dance instructor, martial art instructor, or etc.  But the basic reservation task is the same: agreements on when, where, what, how, who to deliver the lecture.  The classic 5W's.

When: You and your students agree on the time to meet so that a lecture can be delivered.

Where: You have to have a place to deliver the lecture, namely a room, a desk, or on the Internet.

What: You and your students need a subject to talk about, for example: learn a language, learn accounting, etc.

How: After a subject has been fixed, it still remains the method of teaching to be determined.  For example, a language teacher may let his students to choose to focus on listening, writing, or talking; a martial art instructor may let his students to choose to focus on form training, sparring, or movement usage descriptions.

Who: Of course, it involves the instructor and the students.  But it may appear to exist several students and several instructors.  Namely several instructors can build a team to serve their students so that a student can choose one instructor from the team.  And a teacher can teach many students, but only some of the students choose to attend a lecture at a specific time, you want to know who are the students.

To use UORS, you and your students need an account on UORS.  This account is for free.  Whenever you have such an account, this account can be used to access all services provided by Uniwits.com.  Then as an instructor, you need to publish what you teach on UORS, especially address the 5 W's described above.  On UORS, what you teaches is call a service.  You publish a series of lectures as a service.  Don't be scared by the 5 W's, the "Publish Wizard" of UORS helps you to accomplish the task.  Of course, after you get familiar with UORS, you can also publish lectures in your own style.

Up to 2 services can be published for free.  And there are many options available on UORS, such as service option items, button makers, external service list, vacancy time list, etc.

After publishing a service, you want students to know it, so that students can make reservations through UORS.  Often, you write a brief description on some page of your website and add a reservation link on that page, or more easily you add a whole list of reservation icons on that page.  Simply, the "Make Button" tool helps you make single buttons.  And the "External Service List" tool helps you create a whole list of your services.  Both tools let your webpages display reservation links to your students.

It is better to have a try on UORS.  Wish you like it!

ユーザ規約 | UNIWITS.COM よりご提供