Web Transaction Logs, Cookies, Shopping card Database

Web Transaction Logs

In the field of databases in computer science, a transaction log (also transaction journal, database log, binary log or audit trail) is a history of actions executed by a database management system used to guarantee ACID properties over crashes or hardware failures. Physically, a log is a file listing changes to the database, stored in a stable storage format.

If, after a start, the database is found in an inconsistent state or not been shut down properly, the database management system reviews the database logs for uncommitted transactions and rolls back the changes made by these transactions. Additionally, all transactions that are already committed but whose changes were not yet materialized in the database are re-applied. Both are done to ensure atomicity and durability of transactions.

This term is not to be confused with other, human-readable logs that a database management system usually provides.

In database management systems, a journal is the record of data altered by a given process.

All log records include the general log attributes above, and also other attributes depending on their type (which is recorded in the Type attribute, as above).

• Update Log Record notes an update (change) to the database. It includes this extra information:
• PageID: A reference to the Page ID of the modified page.
• Length and Offset: Length in bytes and offset of the page are usually included.
• Before and After Images: Includes the value of the bytes of page before and after the page change. Some databases may have logs which include one or both images.
• Compensation Log Record notes the rollback of a particular change to the database. Each corresponds with exactly one other Update Log Record (although the corresponding update log record is not typically stored in the Compensation Log Record). It includes this extra information:
• undoNextLSN: This field contains the LSN of the next log record that is to be undone for transaction that wrote the last Update Log.
• Commit Record notes a decision to commit a transaction.
• Abort Record notes a decision to abort and hence roll back a transaction.
• Checkpoint Record notes that a checkpoint has been made. These are used to speed up recovery. They record information that eliminates the need to read a long way into the log’s past. This varies according to checkpoint algorithm. If all dirty pages are flushed while creating the checkpoint (as in PostgreSQL), it might contain:
• redoLSN: This is a reference to the first log record that corresponds to a dirty page. i.e. the first update that wasn’t flushed at checkpoint time. This is where redo must begin on recovery.
• undoLSN: This is a reference to the oldest log record of the oldest in-progress transaction. This is the oldest log record needed to undo all in-progress transactions.
• Completion Record notes that all work has been done for this particular transaction. (It has been fully committed or aborted)

Cookies

Cookies are small files which are stored on a user’s computer. They are designed to hold a modest amount of data specific to a particular client and website, and can be accessed either by the web server or the client computer. This allows the server to deliver a page tailored to a particular user, or the page itself can contain some script which is aware of the data in the cookie and so is able to carry information from one visit to the website (or related site) to the next.

Writing data to a cookie is usually done when a new webpage is loaded – for example after a ‘submit’ button is pressed the data handling page would be responsible for storing the values in a cookie. If the user has elected to disable cookies then the write operation will fail, and subsequent sites which rely on the cookie will either have to take a default action, or prompt the user to re-enter the information that would have been stored in the cookie.

Why are Cookies Used?

Cookies are a convenient way to carry information from one session on a website to another, or between sessions on related websites, without having to burden a server machine with massive amounts of data storage. Storing the data on the server without using cookies would also be problematic because it would be difficult to retrieve a particular user’s information without requiring a login on each visit to the website.

If there is a large amount of information to store, then a cookie can simply be used as a means to identify a given user so that further related information can be looked up on a server-side database. For example the first time a user visits a site they may choose a username which is stored in the cookie, and then provide data such as password, name, address, preferred font size, page layout, etc. – this information would all be stored on the database using the username as a key. Subsequently when the site is revisited the server will read the cookie to find the username, and then retrieve all the user’s information from the database without it having to be re-entered.

How Long Does a Cookie Last?

The time of expiry of a cookie can be set when the cookie is created. By default the cookie is destroyed when the current browser window is closed, but it can be made to persist for an arbitrary length of time after that.

Who Can Access Cookies?

When a cookie is created it is possible to control its visibility by setting its ‘root domain’. It will then be accessible to any URL belonging to that root. For example the root could be set to “whatarecookies.com” and the cookie would then be available to sites in “www.tindiafreenotes.com” or “xyz.indiafreenotes.com” or “whatarecookies.com”. This might be used to allow related pages to ‘communicate’ with each other. It is not possible to set the root domain to ‘top level’ domains such as ‘.com’ or ‘.co.in’ since this would allow widespread access to the cookie.

By default cookies are visible to all paths in their domains, but at the time of creation they can be retricted to a given subpath.

Cookies Security

There is a lot of concern about privacy and security on the internet. Cookies do not in themselves present a threat to privacy, since they can only be used to store information that the user has volunteered or that the web server already has. Whilst it is possible that this information could be made available to specific third party websites, this is no worse than storing it in a central database. If you are concerned that the information you provide to a webserver will not be treated as confidential then you should question whether you actually need to provide that information at all.

Cookies Tracking

Some commercial websites include embedded advertising material which is served from a third-party site, and it is possible for such adverts to store a cookie for that third-party site, containing information fed to it from the containing site – such information might include the name of the site, particular products being viewed, pages visited, etc. When the user later visits another site containing a similar embedded advert from the same third-party site, the advertiser will be able to read the cookie and use it to determine some information about the user’s browsing history. This enables publishers to serve adverts targetted at a user’s interests, so in theory having a greater chance of being relevant to the user. However, many people see such ‘tracking cookies’ as an invasion of privacy since they allow an advertiser to build up profiles of users without their consent or knowledge.

Shopping card Database