20
Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading
Rather than Converting
Reason #4: Magic xpa
Provides Superior .NET Transaction Capabilities
Before
you get into the thicket of C#.NET, ASP.NET or Java programming, you might just
want to consider how much more difficult it is to deal with transactions in
these manual languages than it is with the Magic xpa Application Platform.
These 3rd Party Vendors offering Magic Software Migration
services forget that you are going to need to write your own code in C#.NET,
ASP.NET or Java to make up for the transaction capabilities of the Magic xpa
Application Platform.
Business
applications frequently require transactional programming techniques. How
easily one can program a transaction depends on the language and platform. The
Magic xpa Application Platform enhances the .NET platform making it possible
for Magic programmers to create transactions with significantly less effort than
C#, ASP.NET or Java developers.
Transactions
are an integral part of developing data-bound applications. A key to developing
applications in a database environment is the ability to optimally use
transactions to ensure data integrity.
The
word “transaction” is used very often when discussing SQL applications. A
transaction is an integral part of a process, contributing to the composition
of the whole application, and it can be defined as the execution of a set of
logically related data modifications, which must be committed (completed and
written to disk) or aborted as a single unit.
This
means that either the entire process succeeded or the entire process failed.
There is no middle ground. Several operations such as UPDATE, DELETE and INSERT
may create a single unit. Only if all the operations are successful, will this
logical unit be successful.
A
transaction process may be an entire business logic process or a smaller unit
that is part of a business logic process.
Transactions
can be used to secure Read operations, as opposed to Read/Write operations. A
Read transaction ensures that the data read within the transaction is not
modified by other users.
The
transaction processing technique automatically logs all of the updates of a
transaction to a temporary transaction file. The updates in this file are
cleared only when the transaction is complete, that is, the updates to all the
regular database tables have been completed successfully. If a problem is
detected in any of the tables affected by the transaction, the entire
transaction is canceled and the database is rolled back, that is, restored to
its original state before the transaction occurred. The rollback uses the
information stored in the Transaction Log file to restore the project.
Reason #4: Magic xpa
Provides Superior .NET Transaction Capabilities
There
are many challenging issues when implementing transactions using C# or ASP.NET.
The first problem is isolation. The volatile resource must adhere to the
isolation property of ACID, lock the underlying resource it manages, and
prevent access by multiple transactions. However, C#.NET and ASP.NET only offer
thread-based locks, which prevents access only by concurrent threads, not
concurrent transactions. The second problem is state management. The resource
manager needs to enable the transaction to modify the state of the resource and
yet must be able to roll back any such changes if the transaction is aborted.
Magic
xpa offers extensive transaction-handling capabilities that avoid heavy manual
programming efforts in C# and Java. For additional information on how an
upgrade is superior to 3rd
Party Magic Software Migration conversion
please convert here.
