Debug vs Release Mode

PDB Files.

Note:

§ To build ‘Class Library’ type of projects in ‘Release’ mode, you require is to set it to ‘Release’ mode either using toolbar or menu [Build -> Configuration Manager dialog]

§ To build ‘Web Service/Website’ type of projects in ‘Release’ mode, set the ‘debug=false’ attribute in ‘compilation’ tag of Web.config.

§ PDB files are used to store debugging and project state information and they are created when you compile the application.

§ They are required for debugging.

§ A PDB file is created when you compile a Visual Basic/C#/JScript .NET program with /debug.

o The /DEBUG option creates debugging information for the .exe file or DLL.

o The linker puts the debugging information into a program database (PDB). It updates the PDB during subsequent builds of the program.

o An .exe file or DLL created for debugging contains the name and path of the corresponding PDB.

o The debugger reads the embedded name and uses the PDB when you debug the program.

o The linker uses the base name of the program and the extension .pdb to name the program database, and embeds the path where it was created.

§ The major Difference Between Debug And Release is that Optimization Is Turned On And Debug Symbols Are Not Emitted. Most of this optimization is done by the JITR and not the language compiler.

§ Having the solution in Debug mode makes the app run slower, use more memory, etc. It is only necessary for debugging/tweaking. You should only change it to release when you want to use the files in production/live.

§ Release compilations execute faster than Debug.

o The Debug configuration of your program is compiled with Full Symbolic Debug Information in Microsoft format and no optimization (optimization complicates debugging, since the relationship between source code and generated instructions is more complex).

o The Release configuration of your program is fully optimized and contains no symbolic debug information. Debug information may be generated in separate PDB files.

§ Performance is generally better if you compile in release mode, but you will notice a drastic change when errors DO occur because the debug symbols are not created. Therefore, debugging can become significantly more difficult.

§ M. Imp - In Release mode, we cannot attach debugger to the aspnet_wp process. i.e Breakpoints will not work and will behave as below figure.

Thanks & Regards,

Arun Manglick || Tech Lead |

Transaction Support with Error Handling in SQL-Server

Transaction Support with Error Handling in SQL-Server

set ANSI_NULLS ON

set QUOTED_IDENTIFIER ON

GO

ALTER PROCEDURE [dbo].[TestSP]

@RetValue int OUTPUT

AS

DECLARE @error int

BEGIN

BEGIN TRAN

INSERT INTO ERRORLOG VALUES('TESTING')

INSERT INTO TESTTABLE VALUES(1,2.356)

set @error=@@ERROR

IF @error <> 0 -- Error

BEGIN

SET @RetValue= -2

goto errorlog

END

ELSE

BEGIN

COMMIT TRAN

SET @RetValue = scope_identity()

END

PRINT @RetValue

errorlog:

ROLLBACK TRAN

END

Executing the above First time – Insert one row in both the tables

Executing the above First time – Insert one row in ‘ErrorLog’ table then rollback it as the error occurs while inserting in ‘TestTable’.

Thanks & Regards,

Arun Manglick || Tech Lead

MSDN Magzine - Optimization Techniques for Partial Rendering

Optimization Techniques for Partial Rendering

§ AJAX response is made up of two big blocks: Markup And Viewstate.

§ Event validation data (a security-related feature of ASP.NET 2.0), custom hidden fields, scripts, and any other types of nodes usually take just a few dozen bytes all together. The size of the viewstate is an old problem for ASP.NET pages.

§ So what we can reduce is - The markup for a page. Essentially, we can have smaller panels that bring back just the minimum amount of markup you need for that particular click.

So for example-

<asp:UpdatePanel runat="server" ID="UpdatePanel1">

<ContentTemplate>

<asp:TextBox runat="server" ID="TextBox1" />

<asp:Button runat="server" ID="Button1" Text="Update" />

<hr />

<asp:Label runat="server" ID="Label1" />

</ContentTemplate>

</asp:UpdatePanel>

</div>

This code can be optimizzed as below fro minimizing the markup size.

<asp:TextBox runat="server" ID="TextBox1" />

<asp:Button runat="server" ID="Button1" Text="Update" OnClick="Button1_Click" />

<hr />

<asp:UpdatePanel runat="server" ID="UpdatePanel1">

<ContentTemplate>

<asp:Label runat="server" ID="Label1" />

</ContentTemplate>

<Triggers>

<asp:AsyncPostBackTrigger ControlID="Button1" />

</Triggers>

</asp:UpdatePanel>

§ The chart shown below summarizes the potential benefits of applying optimization techniques to updatable panels. With partial rendering, the size of the request packet increases a bit, but even in the least optimized case the response you get back is smaller than in a classic ASP.NET scenario. And, of course, users won't experience flickering.

Thanks & Regards,

Arun Manglick || Tech Lead

How AJAX Postback differs from Regular Postback

To see what makes the rendering stage different for an AJAX postback, take a close lookbelow:

§ A partial rendering request is often referred to as an AJAX postback.

§ An AJAX postback is like a classic ASP.NET postback, except that it is carried out by a piece of script code defined in the client-side ASP.NET AJAX library.

§ Although dressed like a pure AJAX remote call, an AJAX postback, once on the server, the request goes through the same typical lifecycle of postback requests and raises such events as Init, Load, and PreRender.

§ Difference is only in the algorithm it uses to render the final markup. The different algorithm is key to the improved performance and absence of page flickering. However, the application model remains the same as in ASP.NET.

§ Basically the modified rendering process / algorithm for an AJAX postback loops through all updatable panels in the page that are involved with the postback and accumulates the markup of each.

§ All markup chunks, along with hidden fields and any error information, are packed into a response stream and passed to the client.

Now let's dissect a typical partial rendering call in the context of a sample page.

Whenever a page is requested, system detects that an whether its an AJAX postback is occurring. The ScriptManager control checks an HTTP header in the request to determine whether the request is an AJAX postback. The HTTP header is set before triggering the AJAX request by the MicrosoftAjaxWebForms.js file.

Once identified that it's a AJAX PostBack below code fires from the System.Web.Extensions assembly:

protected override void OnPreRender(EventArgs e)

{

base.OnPreRender(e);

if (IsInAsyncPostBack)

PageRequestManager.OnPreRender();

}

The OnPreRender method on the PageRequestManager class does the following:

internal void OnPreRender()

{

_owner.SetRenderMethodDelegate(

new RenderMethod(this.RenderPageCallback));

}

In the preceding code snippet, the method is invoked on the current page and ends up overriding the whole rendering process for the current request.

The actual code responsible for the markup of an AJAX postback is therefore defined in the RenderPageCallback method—an internal method in the PageRequestManager class.

This modified rendering process for an AJAX postback loops through all updatable panels in the page that are involved with the postback and accumulates the markup of each as shown below. All markup chunks, along with hidden fields and any error information, are packed into a response stream and passed to the client.

Whenever the script manager detects one or more UpdatePanel controls in the page, it emits the block of script as in the following

<script type="text/javascript">

Sys.WebForms.PageRequestManager._initialize('ScriptManager1', document.getElementById('form1'));

Sys.WebForms.PageRequestManager.getInstance()._updateControls( ['tUpdatePanel1','tUpdatePanel2'], [], [], 90);

</script>

Hence this way only the piece of code contained in various update panels is updated and not the complete page.

Thanks & Regards,

Arun Manglick || Tech Lead

Serializability and Locking Schemes

Notes on Serializability and Locking Schemes -

When multiple Transaction run concurrently, DB consistency can be destroyed, despite the correctness of the each individual Transaction.

To prevent this we use ‘Concurrency-Control Schemes’

The various ‘Concurrency-Control Schemes’ are as:

- Lock-Based Protocols.

- Two-Phase Locking

- Graph-Based Locking (Skip)

- Timestamp-Based Protocol.

- Validation-Based Protocol.

- Multiple Granularity.

- Multiversion Schemes.

Concurrency-Control Schemes - Are used to ensure that the Concurrent Schedules are Serializable.

Serilaizable means - Assuring that a concurrent schedule will ensure consistency or not. i.e Assuring Serilizability.

Serializability can be ensured in two ways-

- Conflict Serializability

- A concurrent schedule is Conflict Serializable if it is conflict equivalent to a Serial Schedule

- View Serializability

- Leave it

Thanks & Regards,

Arun Manglick || Tech Lead

Reads & Updates in SQL-Server

Following are the problems that occur if you do not implement locking properly in SQL SERVER.

Lost Updates

· Lost updates occur if you let two transactions modify the same data at the same time, and the transaction that completes first is lost.

· You need to watch out for lost updates with the READ UNCOMMITTED isolation level.

· This isolation level disregards any type of locks, so two simultaneous data modifications are not aware of each other.

Non-Repeatable Read

· Non-repeatable reads occur if a transaction is able to read the same row multiple times and gets a different value each time.

· Again, this problem is most likely to occur with the READ UNCOMMITTED isolation level.

· Because you let two transactions modify data at the same time, you can get some unexpected results.

· For instance, suppose that I deposited $500 in my checking account at 10:00 a.m., when my beginning balance was $1000. Also suppose that I have a credit card issued by my bank, on which I owe $1000. While I'm in a process of depositing the check, my wife is applying for a loan over the phone. The loan officer takes down the account number, and runs a stored procedure that returns my checking account and credit card balance. The procedure also brings back the difference between my checking account and credit card balance. The first query brings back $1000 for the checking account and $1000 for the credit card balance because it reads my checking account before the deposit. The second query hits the same table after my deposit is complete and the difference between the two balances shows $500. So the same procedure reads the same row twice and gets two different results, thereby confusing the loan officer.

Dirty Reads

· Dirty reads are a special case of non-repeatable read.

· This happens if you run a report while transactions are modifying the data that you're reporting on.

· Therefore, you might see the changes that haven't been committed.

· Suppose that I intend to withdraw $200 from ATM, and my beginning balance is $1000. I punch in my account number and PIN, and the ATM reduces my balance to $800. At this point, I check my wallet, and am pleasantly surprised that my wife hasn't spent $300 from the last paycheck. I cancel my transaction immediately because I don't feel safe walking around with $500 in my wallet. If a banker were to run a report after I started my transaction but before I cancelled it, my balance would show up as $800, even though I never did withdraw the $200.

Phantom Reads

· Phantom reads occur due to a transaction being able to read a row on the first read, but not being able to modify the same row due to another transaction deleting rows from the same table.

· Interestingly, the phantom reads can occur even with the default isolation level supported by SQL Server: READ COMMITTED.

· The only isolation level that doesn't allow phantoms is SERIALIZABLE, which ensures that each transaction is completely isolated from others. In other words, no one can acquire any type of locks on the affected row while it is being modified.

· For example suppose that a banker would like to offer a low interest rate on an equity loan to all individuals with a balance of $3000 or higher on their checking account. The banker runs a stored procedure that executes two queries. The first query returns names of individuals with a balance of $3000 or higher. The second query brings back the names and addresses of all such individuals. The first query brings back Mr. Green. Mr. Green closes his account at 10:00 AM since he's about to move out of town. The second query does not show Green's address on the list since he no longer holds an account with this bank..

Thanks & Regards,

Arun Manglick || Tech Lead

Learnings - File uploads does not work during async postbacks

Hi,

http://weblogs.asp.net/leftslipper/archive/2007/03/30/why-don-t-file-uploads-work-during-async-postbacks.aspx

File uploads do not work when doing an async postback. To my knowledge there's no way to support this scenario due to the browser's security restrictions.

Reason - understand how async postbacks are different than a regular postback.

When the browser performs a Regular Postback it has the benefit of being actual code with no security restrictions running on the client computer. When you submit a form it creates a web request with all the form fields. When it encounters an <input type="file"> it examines the file the user chose, reads it from disk, and adds it to the web request.

When the AJAX JavaScript code is running in the browser i.e when Async Postbacks occurs it can do the first part about creating a request with all the form fields. However, when it gets to <input type="file"> fields it doesn't have the necessary security permissions to read those files from disk.

Workaround -

· Have a dedicated "Upload" button that does a regular postback instead of an async postback. You can achieve this using several techniques:

o Have the button be outside all UpdatePanels;

o Have the button be the target of an UpdatePanel's PostBackTrigger; or

<Triggers>

<asp:PostBackTrigger ControlID="UploadButton" />

</Triggers>

o Call ScriptManager.RegisterPostBackControl(<Button Control>) on it during page load.

if (!IsPostBack)

{

ScriptManager1.RegisterPostBackControl(UploadButton);

}

· Have a dedicated file upload page that doesn't have any UpdatePanels. Many web sites already do this anyway.

Thanks & Regards,

Arun Manglick || Tech Lead