[Quick Scan]Promises – JavaScript

Promises provide a simpler alternative for executing, composing, and managing asynchronous operations when compared to traditional callback-based approaches. They also allow you to handle asynchronous errors using approaches that are similar to synchronous try/catch
Promise represents the result of a asynchronous transactions.  A Promise represents an operation that hasn’t completed yet, but is expected in the future. It allows you to associate handlers to an asynchronous action’s eventual success value or failure reason. This lets asynchronous methods return values like synchronous methods: instead of the final value, the asynchronous method returns a promise of having a value at some point in the future.

A promise is in one of three different states:

  • pending – The initial state of a promise.
  • fulfilled – The state of a promise representing a successful operation.
  • rejected – The state of a promise representing a failed operation.
Once a promise is fulfilled or rejected, it is immutable (i.e. it can never change again).
In short- Helps you write/manage asynchronous calls easily

Brotli – Small Bread for Chrome is coming !

Google Chrome may be one of the fastest browsers around, but that doesn’t mean there isn’t room for improvement. Starting in the very near future, Chrome’s getting Brotli (“small bread” in Swiss German), a new page compression algorithm that decreases load times.

Brotli, which was revealed in September as a replacement for Chrome’s outgoing Zopfli algorithm, uses a more efficient data format to improve the compression of scripts by up to 26 percent. That should mean faster website rendering and better space utilization in most case, but the potential applications extend beyond mere page content. Compression engineer Zoltan Szabadka sees Brotli being used in image optimization and website pre-fetching on unreliable connections, and perhaps even font compression in scenarios where high-resolution typography isn’t a necessity (e.g., smartphones and other small-screen devices). Subsequently, Google expects all users (but especially those on mobile) to see “lower data transfer fees and reduced battery use.”

Apache Thrift: Networking Stack

Thrift’s networking stack can be represented as follows,

Capture

 Transport:

It provides a simple abstraction for reading/writing from/to the network. This enables Thrift to decouple the underlying transport from the rest of the system (like serialization/deserialization).

Protocol:

This specifies how datatypes use the underlying Transport to encode/decode themselves. Thus the protocol implementation governs the encoding scheme and is responsible for (de)serialization. Some examples of protocols in this sense include JSON, XML, plain text, compact binary etc.

Processor:

Service-specific processor implementations are generated by the compiler. The input and output streams are represented by Protocol objects. The Processor essentially reads data from the wire (using the input protocol), delegates processing to the handler (implemented by the user) and writes the response over the wire (using the output protocol).

Server:

A Server pulls together all of the various features described above.

* Create a transport
* Create input/output protocols for the transport
* Create a processor based on the input/output protocols
* Wait for incoming connections and hand them off to the processor

Windows Tricks: Increase the number of items in Jump Lists

Jump lists are the recent or the pinned items shows when you right click on a particular application in the taskbar.
If you are the person who lean on Jump Items, there may be a time that you have reached the default 10-item in Jump List.
You can increase the number of items in Jump List,
  • Right Click on the taskbar and select properties.
  • Go to Jump List tab
  • Increase the default number of items.

Dive Deep into Oracle DB – Overview of Memory Architecture (2)

The SGA(System Global Area) contains the following data structures:

Database Buffer Cache
The database buffer cache is the portion of the SGA that holds copies of data blocks read from datafiles. All user processes concurrently connected to the instance share access to the database buffer cache. The database buffer cache and the shared SQL cache are logically segmented into multiple sets.

The buffers in the cache are organized in two lists: the write list and the least recently used (LRU) list. The write list holds dirty buffers, which contain data that has been modified but has not yet been written to disk. The LRU list holds free buffers, pinned buffers, and dirty buffers that have not yet been moved to the write list. Free buffers do not contain any useful data and are available for use. Pinned buffers are currently being accessed.

When an Oracle process accesses a buffer, the process moves the buffer to the most recently used (MRU) end of the LRU list. As more buffers are continually moved to the MRU end of the LRU list, dirty buffers age toward the LRU end of the LRU list.

When the user process is performing a full table scan, it reads the blocks of the table into buffers and puts them on the LRU end (instead of the MRU end) of the LRU list. This is because a fully scanned table usually is needed only briefly, so the blocks should be moved out quickly to leave more frequently used blocks in the cache.

Redo Log Buffer

The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database by INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP operations. Redo entries are used for database recovery, if necessary.

Redo entries are copied by Oracle database processes from the user’s memory space to the redo log buffer in the SGA. The redo entries take up continuous, sequential space in the buffer. The background process LGWR writes the redo log buffer to the active redo log file (or group of files) on disk.

Shared Pool

The shared pool portion of the SGA contains the library cache, the dictionary cache, buffers for parallel execution messages, and control structures.
The library cache includes the shared SQL areas, private SQL areas (in the case of a shared server configuration), PL/SQL procedures and packages, and control structures such as locks and library cache handles.

The data dictionary is a collection of database tables and views containing reference information about the database, its structures, and its users. Oracle accesses the data dictionary frequently during SQL statement parsing. This is stored in Dictionary Cache.

Large Pool

The database administrator can configure an optional memory area called the large pool to provide large memory allocations for:

  • Session memory for the shared server and the Oracle XA interface (used where transactions interact with more than one database)
  • I/O server processes
  • Oracle backup and restore operations

Java Pool

Java pool memory is used in server memory for all session-specific Java code and data within the JVM. Java pool memory is used in different ways, depending on what mode the Oracle server is running in.
The Java Pool Advisor statistics provide information about library cache memory used for Java and predict how changes in the size of the Java pool can affect the parse rate.

PGA(Program Global Area) contains the following,

Private SQL Area

A private SQL area contains data such as bind information and runtime memory structures. Each session that issues a SQL statement has a private SQL area. Each user that submits the same SQL statement has his or her own private SQL area that uses a single shared SQL area. Thus, many private SQL areas can be associated with the same shared SQL area.

The private SQL area of a cursor is itself divided into two areas whose lifetimes are different:

  • The persistent area, which contains, for example, bind information. It is freed only when the cursor is closed.
  • The run-time area, which is freed when the execution is terminated.

Session Memory

Session memory is the memory allocated to hold a session’s variables (logon information) and other information related to the session. For a shared server, the session memory is shared and not private.

Dive Deep into Oracle DB: Overview of Memory Architecture (1)

Oracle uses memory to store information such as

  • Program code
  • Information about a connected session, even if it is not currently active
  • Information needed during program execution (for example, the current state of a query from which rows are being fetched)
  • Information that is shared and communicated among Oracle processes (for example, locking information)
  • Cached data that is also permanently stored on peripheral memory (for example, data blocks and redo log entries)
 Oracle
The basic memory structures associated with Oracle include:

  • System Global Area (SGA) and
  • Program Global Areas (PGA).

System Global Area

Group of shared memory structures that contain data and control information for one Oracle database instance. If multiple users are concurrently connected to the same instance, then the data in the instance’s SGA is shared among the users.
Contains general information about the state of the database and the instance, which the background processes need to access.This is called the fixed SGA. No user data is stored here.
Includes information communicated between processes, such as locking information.

Program Global Area

Contains data and control information for a server process. It is a nonshared memory created by Oracle when a server process is started. Access to it is exclusive to that server process and is read and written only by Oracle code acting on behalf of it.
Process SQL statements and to hold logon and other session information.
Large part of the PGA is dedicated to SQL work areas and other SQL operations.