Serializable Isolation level

Similar Questions

• Help me choose an appropriate transaction isolation level

  Hi, gurus please help me with this. Say, I have a table of account balance which has two columns - number. There are two transaction tries to update the same row in this table. For clarification, I'll illustrate what are these two transactions in the diagram.

  *table excerpt*
  Row     Account Number      Account Balance
  1     123                 $100.00
  
    Time                  Transaction1                                                                            transaction2
   T1              read Row 1 (return $100 ,then save it to a Java variable Ret)                                   ------
   T2              update Row 1(update balance to the addition of $100 and Ret )                     read Row 1 (return $100 ,then save it to a Java variable Ret)           
   T3              read Row 1                                                                        update Row 1(update balance to the addition of $100 and Ret ) 
   T4              commit                                                                                commit                                           

  After the validation of transaction2, the account balance will update to $200(i am suppose that oracle using Read Committed as a default Isolation Level), but actually, I'd like to wait it is $300. These transactions can normalize to the transaction of real cases in which a customer trying to deposit $ 100 to its balance and at the same time, another customer, you are trying to transfer $100 in his account. My question is what level of insulation should I choose to make my expectation.or if this issue is not only a matter of selecting the right isolation level, please give me an overview on another problem that I should. Thank you!

  Looks like you are dealing with the problem of the "lost update": you can still use read committed level isolation but you need to lock data (pessimistic locking) or use a way to detect changes (optimistic locking).

  See the complete description of these solutions in the article Tom Kyte "Locking and concurrency" section "updated lost" in
  http://www.DBAzine.com/Oracle/or-articles/kyte1.

• Setting the isolation level

  Hello
  
  I converted our application of transaction is not entitled to use transactions. I want to reduce the impact on performance, I setup some transactions to some lesser isolation levels. As I understand the documentation, the General method to do is to set the isolation level appropriate in TransactionConfig when you create a transaction.
  
  But what I see in the documentation, it is possible to PrimaryIndex.get () third (lockMode) parameter allows you to specify isolation for the specific operation as well.
  
  So my question is: what are the disadvantages of configuring isolation per-operation compared with the isolation by transaction configuration and accessories?
  
  I.e. I'm considering the approach which is better:
  
  1.
  ----
  TransactionConfig txnConfig = new TransactionConfig();
  txnConfig.setReadUncommitted (true);
  Transaction txn = myEnv.beginTransaction (null, txnConfig);
  for (id: idList)
  {
  primaryIndex.get (txn, id, null);
  }
  ----
  
  2.
  ----
  Transaction txn = myEnv.beginTransaction (null, null);
  for (id: idList)
  {
  primaryIndex.get (txn, id, LockMode.READ_UNCOMMITTED);
  }
  ----
  
  In general, I understand that specifying the isolation on a basic per-operation probably was to be used as a tool to locally modify the General transaction as a parameter
  
  3.
  ----
  TransactionConfig txnConfig = new TransactionConfig();
  txnConfig.setReadUncommitted (true);
  Transaction txn = myEnv.beginTransaction (null, txnConfig);
  for (id: idList)
  {
  primaryIndex.get (txn, id, id == 5? LockMode.READ_COMMITTED: null);
  }
  ----
  
  but I want to know if the 2nd approach is legal and that it would not lead to some bad consequences.

  Mikhail,

  Blocking rules described in http://www.oracle.com/technology/documentation/berkeley-db/je/java/com/sleepycat/je/LockMode.html will help you to understand the interaction between operations and blocking rules. From there, you should see that specification of a lock at the level of the operation mode cancels and replaces all other levels of specifications.

  In general, I understand that specifying the isolation on a basic per-operation probably was intended to be used as a > tool to change the setting of General transactions such as locally

  Exactly, it's just an option of the API.

  When you ask if (1) or (2) is better, both are equivalent, although it seems unusual that a transaction where you always choose to use READ_UNCOMMITTED. However, there are no differences in efficiency, and the choice must be made of the way in which it matches your code.

  Kind regards

  Linda

• How to get a level lock share line

  Is it possible to acquire a lock for sharing at the level of the lines, that would make all of the following conditions?
  1 prevent other update of this line.
  2. allow others to read this line.
  3. to allow others to update the other rows in the same table.
  
  
  I have the following scenario, where both transactions need eachother lockout:
  
  Implementation:
  Insert into TABLE_A (value_a) values ('ok');
  Insert into TABLE_B (value_b) values ('ok');
  
  Transaction r:
  Select value_b from TABLE_B
  If value_b = "ok", TABLE_A update set value_a = "not ok".
  
  Transaction B:
  Select value_a in the TABLE_A
  If value_a = "ok", TABLE_B update set value_b = "not ok".
  
  If transaction A runs first and then the final result is not 'ok' in the TABLE_A.
  If transaction B runs first and then the final result is not 'ok' only to TABLE_B.
  If both operations are running at the same time, it is possible to get the "not ok" in both tables. That's what I would like to prevent.
  
  
  A way to get what I want is to use "select for update":
  
  Transaction r:
  Select value_a in the TABLE_A for update
  Select value_b from TABLE_B for update
  If value_b = "ok", TABLE_A update set value_a = "not ok".
  
  Transaction B:
  Select value_a in the TABLE_A for update
  Select value_b from TABLE_B for update
  If value_b = "ok", TABLE_B update set value_a = "not ok".
  
  In this way that the two transactions will not perform their update unless they know the result if their selection will always be the same after that they commit. However, using "select for update" Transaction A has acquired an exclusive lock on the line TABLE_B. If a Transaction of C with the same content that the Transaction occurs simultaneously, then the two will be block eachother, even if both want is to read data from the same table.
  
  Another way is to use "lock table', however using it would block not only written on a specific, but written line in all the rows in the table. (In my example, there is only one line, but of course, this is just a simplified example).
  
  I looked at the "serializable" isolation level, but this doesn't seem to help because the queries and updates involve more than one table.
  
  
  I know that "readings do not block writes" is a fundamental part of the design of Oracle that makes Oracle what it is, but is it possible that I can do it explicitly will pass anyway? Or can you see another solution to what I want to achieve?

  Oracle does not have level shared row locks. The single line level lock oracle knows / uses is exclusive.
  The fact for example postgres (the syntax is... FOR ACTION) and the idea is exactly as above: you want to make sure that no other changes/deletions row but more than one transaction can contain this "guarantee" at the same time.

• DBMS_MVIEW. UPDATING and ISOLATION_LEVEL

  I'm having a hard time to understand behavior with DBMS_MVIEW. REFRESH and my transaction isolation level. If I set the Serializable isolation level, it does appear that DBMS_MVIEW. DISCOUNT respects it. I have provided an example of what I mean. I tested with two ATOMIC_REFRESH of FALSE and true to see if that makes a difference, but it did not. I have also provided an example with an ordinary table which IS working to show that my essay is not wrong and what I expect the behavior should be.
  
  It looks like DBMS_MVIEW. REFRESH could be committed BEFORE it queries the primary table for the data, but I didn't know that, especially when ATOMIC_REFRESH is set to TRUE, it would / should do.
  

  Connected to:
  Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
  With the Partitioning, Real Application Clusters, OLAP and Data Mining options
  
  SQL> ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE;
  
  Session altered.
  
  SQL>
  SQL> DROP TABLE t;
  
  Table dropped.
  
  SQL> DROP TABLE u;
  
  Table dropped.
  
  SQL>
  SQL> CREATE TABLE t ( x INT );
  
  Table created.
  
  SQL> CREATE TABLE u ( x INT );
  
  Table created.
  
  SQL>
  SQL> INSERT INTO t VALUES ( 1 );
  
  1 row created.
  
  SQL>
  SQL> ALTER TABLE t ADD CONSTRAINT t_pk PRIMARY KEY ( x );
  
  Table altered.
  
  SQL>
  SQL> COMMIT;
  
  Commit complete.
  
  SQL>
  SQL> DROP MATERIALIZED VIEW t_mv;
  
  Materialized view dropped.
  
  SQL>
  SQL> CREATE MATERIALIZED VIEW t_mv
    2  USING NO INDEX
    3  REFRESH COMPLETE ON DEMAND AS
    4  SELECT *
    5    FROM t;
  
  Materialized view created.
  
  SQL>
  SQL> SELECT *
    2    FROM t;
  
           X
  ----------
           1
  
  SQL>
  SQL> SELECT *
    2    FROM t_mv;
  
           X
  ----------
           1
  
  SQL>
  SQL> DECLARE
    2    PRAGMA AUTONOMOUS_TRANSACTION;
    3  BEGIN
    4    UPDATE t
    5       SET x = 2;
    6
    7    COMMIT;
    8  END;
    9  /
  
  PL/SQL procedure successfully completed.
  
  SQL>
  SQL> SELECT *
    2    FROM t;
  
           X
  ----------
           1
  
  SQL>
  SQL> BEGIN
    2    dbms_mview.refresh(list           => 't_mv',
    3                       atomic_refresh => TRUE);
    4  END;
    5  /
  
  PL/SQL procedure successfully completed.
  
  SQL>
  SQL> SELECT *
    2    FROM t_mv;
  
           X
  ----------
           2
  
  SQL>
  SQL> DECLARE
    2    PRAGMA AUTONOMOUS_TRANSACTION;
    3  BEGIN
    4    UPDATE t
    5       SET x = 3;
    6
    7    COMMIT;
    8  END;
    9  /
  
  PL/SQL procedure successfully completed.
  
  SQL>
  SQL> SELECT *
    2    FROM t;
  
           X
  ----------
           2
  
  SQL>
  SQL> BEGIN
    2    dbms_mview.refresh(list           => 't_mv',
    3                       atomic_refresh => FALSE);
    4  END;
    5  /
  
  PL/SQL procedure successfully completed.
  
  SQL>
  SQL> SELECT *
    2    FROM t_mv;
  
           X
  ----------
           3
  
  SQL>
  SQL> SELECT *
    2    FROM t;
  
           X
  ----------
           3
  
  SQL>
  SQL> DECLARE
    2    PRAGMA AUTONOMOUS_TRANSACTION;
    3  BEGIN
    4    UPDATE t
    5       SET x = 4;
    6
    7    COMMIT;
    8  END;
    9  /
  
  PL/SQL procedure successfully completed.
  
  SQL>
  SQL> INSERT INTO u
    2  SELECT *
    3    FROM t;
  
  1 row created.
  
  SQL>
  SQL> SELECT *
    2    FROM u;
  
           X
  ----------
           3
  
  SQL>
  SQL> COMMIT;
  
  Commit complete.
  
  SQL>
  SQL> SELECT *
    2    FROM t;
  
           X
  ----------
           4
  
  SQL>
  SQL> SELECT *
    2    FROM u;
  
           X
  ----------
           3

  According to Tom Kyte (http://asktom.oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:4541191739042).
  Oracle considers refreshing a MV a DDL and emits an implicit validation.
  It may make more sense, but that's how.
  That's the problem, you might consider refreshing the MV of a standalone transaction.

  Lordane Iotzov
  http://iiotzov.WordPress.com/

• Inconsistency of data

  Hello
  
  I feel this brainstorming session, which I'll try to find a solution for:
  
  1. first session initiates a transaction T1.
  A multiple inserts take place, as the entire operation may continue for some time.
  A fragment of what does the insert statement:

  INSERT INTO tab1 (column1, column2, problem_column3)
  VALUES (value_column1,  value_column2, (SELECT problem_column_value FROM dist_table WHERE id = <XXX> AND status = 0 AND <other conditions>));

  Either all insertions must pass with success or none of them. In other words, even if a single insert fails, all insertions must be cancelled. They loop in a cycle, one after another and take the time to finish.
  
  2 another session initiates a transaction T2.
  There is an update statement that updates the same row in the dist_table table exactly what query T1 for the problem_column_value:

  UPDATE dist_table SET status = 1 WHERE id = <XXX>

  Now the situation has become from 0 to 1, but it is only visible for the T2. T2 still does not issue a commit.
  
  3 T1 has already done some inserts successfully and continue to insert new lines. T1 'think' the line, that it refers to dist_table a "Status" column equal to 0.
  
  4 T2 commits. Dist_table line already has his column "status" different from 0 (it is now 1) and it is now visible to the world.
  
  5 T1 continue to insert. Its previous inserts (before the validation of the T2) are effective and they took dist_tablesuccessfully. His next inserts however (after the validation of the T2) will also succeed, BUT they will not find the dist_tableline, because the 'status' is not 0 more, but now it is 1.
  
  6 T1 ends, there is no errors and T1 commits.
  
  What happened: the problem_column3 of tab1 table column is filled with a value of a dist_table line which line SHOULD always have its 'Status' column equal to 0. But this isn't like that.
  
  What can we do to escape this trap?
  
  I thought using transaction (T1) with serializable isolation level, but T1 actually never update dist_table. He just asks it.
  
  In addition, during the T1 knows exactly which lines will interview of dist_table. It can query a variety of lines, questionable one - the same for all insertions.
  
  DB version: 10.2.0.4.0

  Hello!

  I tried to simulate your problem... isolation_level = serializable works for my case...

  session 1

  SQL> commit;
  
  Commit complete.
  
  SQL> alter session set isolation_level=serializable;
  
  Session altered.
  
  SQL> insert into ttt(v) select sal from emp where ename = 'ALLEN';
  
  1 row created.
  
  SQL>  insert into ttt(v) select sal from emp where ename = 'ALLEN';
  
  1 row created.
  
  SQL> commit;
  
  Commit complete.
  
  SQL> select v from ttt;
  
  V
  --------------------------------------------------
  1100
  1100
  
  SQL> 
  

  session 2

  SQL>
  SQL> update emp set sal = 1100 where ename = 'ALLEN';
  
  1 row updated.
  
  SQL> commit;
  
  Commit complete.
  
  SQL> update emp set sal = 900 where ename = 'ALLEN';
  
  1 row updated.
  
  SQL> commit;
  
  Commit complete.
  
  SQL> 
  

  first validation in session 2A was made before the opening of transaction in the session 1
  second session 2A verification was conducted between insertions in session 1

  isolation_level = serializable should satidfie your condition, if I understand the right to prescription

  Of course-, you should also take care about potential problems with size cancellation
  I was testing on V 11.1.0.7

  T

  Published by: ttt on 17.3.2010 02:50

• transaction isolation stored procedure-level testing

  Hello

  I want to study the concurrency in the Oracle database using stored procedures in pl/sql with different transaction isolation levels.

  The idea is to send to the database of a number "n" of simultaneous transactions where n can be {100, 200, 400, 1000} and for each isolation level (READ COMMITTED, SERIALIZABLE) to determine the number of transactions committed, how much data, run time incorrect.

  The question is how can I generate n transactions that run simultaneously on the data base and how to get these results. I understand that this task can be done as well by using pl/sql stored procedure in the database or inside a JSP Java web application. Advantages/disadvantages?

  I should mention that I'm a begginner in Oracle...

  Thank you in advance.

  You want to run a large number of asynchronous (parallel) transactions.

  Although this can be done by running the Oracle's work, I think it is easier to work with the client side, using a Java program (for example).

  It doesn't have to be a web application (for example. JSP), can be a client Java that uses Java threads, and each thread is using a single database connection (and the corresponding database session).

  Kind regards

  Zlatko

• Creation of Hyperion Planning App ORA-08177: can't serialize access for this transaction

  Hello

  I installed Hyperion Planning 11.1.2.3 on linux 32-bit and trying to create my first application.  I have validated my datasources and uses the wizard to create my first sample application.  When I click on create, I get an error and inside the /home/oracle/Middleware/user_projects/domains/EPMSystem/servers/EPMServer0/logs/Planning_WebApp.log error is:

  Error running query SQL_ADD_ACTIVITY_LEASE with parameters [1, 1138881444, 11:01:27.0 2014-07-06] []

  java.sql.SQLException: ORA-08177: can't serialize access for this transaction

  Is it because a certain table is locked and I need to unlock it in the comic book? Any idea would be appreciated.

  Thank you!

  Hello

  1. log in DB used for the validation of data source and enter the command below

  set the serializable transaction isolation level.

  COMMIT;

  2. restart planning services

  3. try to create an application

  Thank you

  Sreekumar heraud

• ORA-08177: can't serialize access for this transaction

  We are faced with ORA-08177: can't serialize access for this transaction
  On the next sql run in the order of appearance is:
  
  0-SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
  1. update date_allocated_number set dan_number = 1 where sng_id = 1;
  2 - Select min (dan_number) dan date_allocated_number where sng_id = 1;
  3 update sequential_number_group set sng_number = sng_number + 1 when sng_id = 1;
  4 - Select sng_number from sequential_number_group where sng_id = 1;
  5 - Insert into a values (2,1,sysdate,1,'N',1,1) date_allocated_number (dan_id, sng_id, dan_dttm, dan_number, dan_delete_fl, dan_version_id, ptn_id);
  6 - INSERT INTO SID. SEQUENTIAL_NUMBER_GROUP (SNG_ID, CMP_ID, SNG_NAME, SNG_NUMBER, SNG_DELETE_FL, SNG_VERSION_ID, PTN_ID)
  VALUES (1, 374, 'Case number Group', 1, 'n', 1, 1);
  7 validation;
  
  get ORA-08177: can't serialize access for this transaction
  
  This is observed in Oracle11g.
  
  Thank you
  SID

  What version of Oracle?

  Are there already data in DATE_ALLOCATED_NUMBER or is it empty? (e.g. creation of segment delayed)
  See Metalink - ORA-08177: can't serialize access for this Transaction After Upgrading To 11.2 [ID 1285464.1]

• Transaction in stored procedure not treated as Atomic?

  Hello

  I have a stored procedure that inserts a line in a table called reservations and also decrement the places available for an event.

  For example: at an event, there are 100 places available. After you add a reservation, it will be left only 99 seats.

  I also have a Java program that sends 100 concurrent transactions to the database.

  After 100 transactions, there are 100 reservations, but there are still about 60 free places.

  So, I guess that the transaction he has not treated as atomic. I don't know why some transactions fail?

  The code of the stored procedure:

  create or replace PROCEDURE procedureOne (s_price, NUMBER, NUMBER, of s_customer)

  s_event NUMBER, DATE, s_movie NUMBER of s_dat)

  IS

  s_ev NUMBER;

  s_free NUMBER: = 0;

  BEGIN

  commit;

  Set transaction read write;

  Start

  SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

  Select Event_ID, Free_seats EN s_ev, s_free

  events

  where ID_Movie = s_movie;

  If s_free > 0 then

  Start

  update events set Free_seats = s_free-1;

  insert into values of reservations (seqa_seq. NEXTVAL, s_dat, s_customer, s_event, s_price);

  commit;

  end;

  on the other

  Start

  Rollback;

  end;

  end if;

  end;

  commit;

  end procedureOne;

  invatacelul wrote:

  So, I guess that the transaction he has not treated as atomic. I don't know why some transactions fail?

  You said: "I also have a Java program that sends 100 concurrent transactions to the database. Atomicity applies to a single transaction - it says transaction executes all or nothing. Is what you run in isolation. If you want isolation unless you serialize, transaction 2 sees no uncommitted transaction 1 results because the READ COMMITTED isolation level indicates that a transaction can read only the data that has been committed to the database. And since you wrote your code as SELECT + UPDATE you get results you never expected. Use:

  UPDATE OF EVENTS

  SET FREE_SEATS = FREE_SEATS - 1

  WHERE ID_Movie = s_movie

  AND FREE_SEATS > 0;

  SY.

• Support of nested transaction?

  Hi just out of curiosity,.

  
  I did not understand si Oblade supports nested transactions (not standalone).

  For example, to be sure only a procedure is called with insulation Serializable you could write:

  
  

  SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

  ... the DML statements
  

  COMMIT or ROLLBACK (COMMIT is ignored by the appellant but signals the end of the internal transaction).
  

  
  

  If so this are the consequences on the transaction caller?

  
  

  Claudio

  No, Oracle does not support nested transactions in the way do of other databases (Sybase and SQL Server for example).  If you engage in your procedure, any uncommitted work the appellant did in the current session is committed.  You can't, as in SQL Server, starts a new transaction nested within your procedure, who can commit (or rollback) without affecting the State of the parent transaction.  It is one of the reasons it would be very unusual to have any sort of control transaction in an Oracle stored procedure statement - it is exceptionally difficult to reuse this procedure somewhere else which has requirements different transactions.

  As Boneist, a large part of what you can do in SQL Server with nested transactions can be made with the recording points in Oracle.  You can create a backup in a stored procedure, and then return to this backup point, returning just the work of your procedure without affecting uncommitted from the rest of the transaction data.  Who will not allow you to run some parts of your transaction to a transaction isolation level and other parts in a different isolation level, however.

  Justin

• Solution problem Halloween in Oracle

  Can someone help me to know how it is addressed the problem of halloween in Oracle?

  And, as I said, Oracle that resolve in ensuring that each block (index or table) is read from the SNA started application (or the RCS at the beginning of the transaction, if you use a serializable transaction isolation level).

  In reality, this is not a problem with any database published in the last decades of the couple. You're talking about something that has been identified in 1976 at the beginning of the relational databases.

  Justin

• CFTRANSACTION: I use it wrong?

  Just so we don't have too far off track, keep in mind the code samples below are not my real code. I'm stripping things down only for purposes of illustration - I realize that they are bad examples and have no CFQUERYPARAM.

  So, to give a little history first... I started my career as ColdFusion programming, more than a decade of creating large enough e-commerce applications. No Amazon scale, but not by all means shopping carts.

  In the meantime, I have often used CFTRANSACTION for situations where several queries INSERT or UPDATE is supported on the other. For example, a form that fits a new product in a database table and the inventory count in a separate table.

  For example:

  < cftransaction >

  < cfquery datasource = 'mydatasource' result = "product_inserted" >

  INSERT INTO products (Ref, price, title)

  VALUES ('555-555, 2.50, 'Spider-Man T-Shirt')

  < / cfquery >

  
  

  < cfquery datasource = 'mydatasource' >

  INSERT INTO Inventory (product_id, inventory)

  VALUES (#product_inserted.) IDENTITYCOL #50)

  < / cfquery >

  
  

  < / cftransaction >

  
  

  This ensures that the two tables is written in. If a query fails for any reason, the other will be not committed to the database.

  
  

  Somewhere along the line but I started which, according to me, is a useless (and maybe bad) practice.

  
  

  In some applications, I have a ColdFusion model, which (when passed an identification number via a URL variable) allows the user to edit a record via a form.

  
  

  The first action of the page is to check for the required URL variable and then pulls the records in the database. It then displays the record in a form for editing.

  
  

  When the form is submitted, the page obviously checks the URL variable once again, the required form fields and then queries to ensure that the record exists (that you don't want to continue with the UPDATE if the URL variable is not a record valid, right?

  
  

  Thus, the processing page for update form can have code like this:

  
  

  < cftransaction >

  
  

  < cfquery name = "find_product" datasource = 'mydatasource' >

  SELECT *.

  PRODUCTS

  WHERE id = #url.sku #.

  < / cfquery >

  
  

  (a code here that verifies the data in the form to the appropriate type, etc.)

  
  

  < cfquery datasource = 'mydatasource' >

  UPDATE products

  SET myfield = #form.myfield #,.

  AnotherField = #form.anotherfield #.

  WHERE id = #find_product.sku #.
  

  < / cfquery >

  
  

  < / cftransaction >

  
  

  You see what I did there? Somewhere along the line in the history of my programming I began all suddenly put CFTRANSACTION tags around blocks of code that used multiple queries, generally a SELECT statement, then an UPDATE statement that updates to the file found via the SELECT statement. I started to treat the CFTRANSACTION as a kind of 'lock', thinking that it was somehow ensure that the SELECTION and the UPDATE statement have been uninterrupted by another another user which may be to rely on the same page, in order to avoid a race to the record being edited conflict. Please someone put my mind at ease and tell me what of actually not accomplish that and all I do is slowing down my DB process?

  
  

  If my hunch is correct, and I had a frivolous/bad habit for years, what would be the right way to avoid the above scenario?
  

  In my opinion, what you did is correct. What you describe is a case of use editing for cftransaction. The cftransaction tag tells the management system of database to manage queries 2 or more as a single transaction. They all succeed or all fail together.

  You are also right in the treatment of the cftransaction as "a sort of blocking. Isolation of the tag attribute determines the level of locking.

  For example, = "read_uncommitted" insulation is level lowest. It allows 'readings', in which case a single transaction can read, yet, uncommitted changes made by other transactions. The highest isolation level is "serializable." It prevents in principle a read operation from the data being modified by other transactions, until the changes have been committed or canceled and all the locks released.

  ColdFusion has nothing to say to that. Responsible for locking of the database with the database management system, and every brand of database has its own blocking rules.

  If you specify no value for the attribute of isolation, the database will use its own default isolation level. The default value for SQL Server and Oracle is "read_committed". MySQL (InnoDB) is "repeatable_read.

• Types of locks TimesTen

  Hello
  
  After observing the results of ttxactadmin,
  

  Resource  ResourceID           Mode  SqlCmdID             Name
  
  Row       BMUFVUAAAC2BwAALDe   Xn    8416776768           USER1.TABLE1
  Row       BMUFVUAAABGEAAABgz   Xn    8416766544           USER1.TABLE1
  Table     12144968             IXn   8416766544           USER1.TABLE1
  Row       BMUFVUAAABPEAAAFhL   Xn    8416493904           USER1.TABLE2
  Table     719136               IXn   8416493904           DUSER1.TABLE2
  Row       BMUFVUAAACoFAAAIBt   Xn    8413989000           USER1.TABLE3
  Table     721136               IXn   8413989000           USER1.TABLE3

  Can you please help me with documentation on different types of modes of locking in timesten and how timesten performs a table-level lock.
  
  Kind regards
  Karan

  Hi Kiki,

  Documentation is here (http://docs.oracle.com/cd/E21901_01/doc/timesten.1122/e21643/util.htm#BJEDDACF, see instructions)

  Just in case:

  The value that is used to determine the level of concurrency that provides the lock:

  S - lock shared isolation serializable.
  SN - lock shared in isolation not serializable.
  U - lock in isolation serializable update.
  UN - lock update in not serializable isolation.
  En - end-of-scan lock not serializable isolation.
  IRC - Shared intent lock not serializable isolation.
  IS - Shared intent lock in isolation serializable.
  UI - lock of the Intention in isolation serializable update.
  Bud - lock to update the Intention in not serializable isolation.
  IX - Exclusive intent lock isolation serializable.
  Viin - isolation not serializable exclusive lock intent.
  SIX - shared lock with the intention to put an exclusive lock in the serializable isolation.
  SIXn - shared lock with the intention of putting a not exclusive lock serializable isolation.
  X - exclusive lock.
  XN - exclusive lock in isolation not serializable.
  W - update, insert, or delete the table lock.
  Number - then block for inclusion in tables or non-unique indexes.
  NS - Table lock in read committed isolation that comes into conflict with all table locks to serializable isolationLock '0' means that the blocker is still in the queue.

  Best regards
  Gennady

• ORA-08177 implemented Parallels updated

  Hello
  A few days ago I had a problem when I get an error ORA-08177.
  
  I have 2 processes running in parallel and each update one line in a particular table, but not the same line.
  They ran each night for about 3 months and I never had a problem with that, but once that they collapsed with an ORA-08177 and when I restarted them I got the same error again once, had to run in order to solve the problem.
  
  I am using Oracle 11g and the table that these processes are up to date has inittrans = 1 and PCTUSED = null.
  I'm guessing that this particular day two ranks where on the same block and this block must have been full and had no space to expand the transaction header, so I need to increase inittrans 2 or set some limit to PCTUSED while I still have free space in blocks.
  I want to know if this makes no sense, or I'm trying to solve the problem in the wrong way.
  
  
  
  Thank you

  $ oerr ora 8177
  08177, 00000, "can't serialize access for this transaction"
  // *Cause:   Encountered data changed by an operation that occurred after
  //           the start of this serializable transaction.
  // *Action:  In read/write transactions, retry the intended operation or
  //           transaction.
  

  I'm not sure something to do with the INITRANS parameter, but it is more likely, that this has something to with the transaction isolation level that seems to be serializable value. Using serializable transactions? If so you are sure that it is really necessary to your application?

  Edited by: P. Forstmann on 17 Jan. 2011 17:27

  Edited by: P. Forstmann on 17 Jan. 2011 17:37