Transactions
is a set of database commands that are treated as a single
unit.
Commands
can be treated as transaction if
Atomic: Each command
should perform single unit of work independently.
Consistent: All the
relationships between data are maintained correctly.
Isolated: Changes made by other
clients can’t affect the current changes.
Durable: Once a change is made,
it is permanent.
Transaction
processing follows these steps
Begin a
transaction,
Process database commands,
Check for
errors. If errors occurred, restore the database to its state at
the beginning of the transaction,
If no errors occurred,
commit the transaction to the database.
IsolationLevel
property is the property of transaction objects
that handles concurrent changes to a database.
Isolation
Level Settings
ReadUncommitted does not
lock the records being read,
Chaos,
ReadCommitted locks the records being read and
immediately frees the lock as soon as the records have been read,
RepeatableRead locks the records being read and
keeps the lock until the transaction completes,
Serializable locks the entire data set being read
and keeps the lock until the transaction
completes.
Exceptions
are unusual occurrences in the code of application. Dealing with
unusual occurrences is called exception handling. Errors that are
not handled are called unhandled exceptions.
Ways
to handling exceptions in ASP.NET
are
Exception-handling structures,
Error
events,
Custom error pages.
Exception-Handling
Keywords: Try/try, Catch/catch, Finally/finally, End
Try and Throw/throw
Finally/finally:
Free resources used within the Try/try section and process any
other statements that must run, whether or not an exception has
occurred
Exception-Handling
Error Events
Page_Error resides in the
web form,
Global_Error resides in the Global.asax
file,
Application_Error resides in the
Global.asax file.
Server
Object’s Exception-Handling Events
GetLastError
ClearError
Error
pages can be .htm or .aspx where users are
redirected when unhandled exception occurs.
We can
define error page at two level: CustomErrors section
of the Web.config file. ErrorPage attribute of the Web form’s @
Page directive.
The
customErrors mode attribute must be On
to view the error pages. RemoteOnly (the default) means error will
be displayed at the client machine and not
locally.
The
page-level setting supersedes the
application-level settings in the Web.config
file.
Exception
log provides a list of handled exceptions. Use the
Throw/throw keyword to intentionally cause an
exception.
Tracing
records events, a way to record errors by writing error message in
the file.
Steps
to use tracing in ASP.NET
Turn tracing
on
Write to the trace log
Read the trace
log
Tracing can be
turned on or off for an entire Web application or for an
individual page
For an entire
application, set the element’s Enabled attribute to True in
Web.config file.
For a single page,
set the @ Page directive’s Trace attribute to True in the Web
form’s HTML.
The
Trace object provides the Write and Warn
methods.
Messages written
with Write are in black, whereas messages written with Warn are in
red.
By default, trace
output is displayed at the bottom of each Web page, if the
element’s PageOutput attribute is set to False in the
Web.config file, otherwise written to the Trace.axd file.
By default, you
can view Trace.axd only from the local
server running the application.
To
view the trace log from a remote machine, such as
when debugging remotely, set the element’s LocalOnly
attribute to False in the Web.config file.
Users
can be identified using Cookies. Cookies are small
files that a web application can write to the client. Cookies
allow interaction with user invisibly. Users can set their
browsers not to accept cookies. Approaches when storing and
retrieving user information through cookies: Store all the user
information as a cookie on the client’s machine. Store an
identification key and retrieve user information from a data
source using
key. .
