Assert enable in jdeveloper

JDK 1.4 and the Assert Keyword (2394626,2394613)
The parser and the code editor do not know about the 'assert' keyword yet. The workaround to enable JDK 1.4 assert keyword support
in the code editor is to uncomment the following line in the $(JDEV_INSTALL_DIR)\jdev\bin\jdev.conf file, and restart JDeveloper:

AddVMOption -DEDITOR_ENABLE_ASSERT=true

Or
go to weblogic bin folder and edit setDomainEnv.bat file
and search
'set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -da'
then change it to

'set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -ea'
if you want to change default server then you will find bin folder in
system11.1.1.1.33.54.07\DefaultDomain\

How can we find row level changes while you updating a row?

When ever you are creating table, you need to give ROWDEPENDECIES with the CREATE Statement.
After you can access a psuedo column ORA_ROWSCN to get the state of perticular column. ORA_ROWSCN in your update clause to ensure that the row has not changed since the last time you read it
Example
Whene ever you access a record from table you need to get ORA_ROWSCN number store it with your record.
Update tablename set column where id=1 and ORA_ROWSCN= stored number.
if the staement execute none you can tigger the user,that the record has changed somewhere else.

Overcome Concurrency Limitations

Here is how you can solve the concurrency-limiting problem demonstrated in my test case using ROWDEPENDENCIES. The following code creates a new set of tables, opens two SQL*Plus sessions, and executes an anonymous block:

/* create the tables for the test case */
create table t1_rd (c1 number) rowdependencies pctfree 5;

create index idx_t1_rd on t1_rd(c1) pctfree 5;

/* now open 2 SQL*Plus sessions and cut-paste this code in both */

/* session 1*/
alter session set isolation_level=serializable;

begin
FOR i IN 1..10000
  LOOP
    insert into t1_rd values(i);
  END LOOP;
end;


/* session 2*/
alter session set isolation_level=serializable;

begin
FOR i IN 1..10000
  LOOP
    insert into t1_rd values(i);
  END LOOP;
end;

/* now in both sessions, execute the anonymous block*/

/* session 1 */
SQL>/

/* session 2*/

SQL>/
Here is the output from both sessions:

SQL> alter session set isolation_level=serializable;

Session altered.

SQL> begin
  2  FOR i IN 1..10000
  3    LOOP
  4      insert into t1_rd values(i);
  5    END LOOP;
  6  end;
  7  /

PL/SQL procedure successfully completed.

The code produced no errors. Now you can commit or rollback to end the transaction. After commit, you can see the rows inserted in the table.
Determine Which Rows Have Been Committed
You can use ROWDEPENDENCIES to determine which rows have been committed and which rows haven't been committed yet by the same session.

INSERT INTO t1_rd VALUES (100);

INSERT INTO t1_rd VALUES (101);

SELECT c1, ORA_ROWSCN FROM t1_rd WHERE ORA_ROWSCN IS NULL;

INSERT INTO t1 values (1000);

INSERT INTO t1 values (1001);

SELECT c1, ORA_ROWSCN FROM t1;

In tables with ROWDEPENDENCIES, the ORA_ROWSCN column is NULL for uncommitted rows.
With these techniques, you can improve application concurrency and avoid that dreaded ORA-8177 error.

A Java API for XQuery

A Basic Example
Here's a basic code example that uses XQJ to execute a query that illustrates a typical use. Note that error handling has been omitted for clarity.

   // obtain an XQDataSource instance
   XQDataSource xqds = (XQDataSource)
      Class.forName("com.jsr225.xqj").newInstance();
   // obtain a connection
   XQConnection con = xqds.getConnection("usr", "passwd");
 
   // prepare an XQuery Expression
   String xqry = "for $i in fn:collection('dept') " +
      "where $i/deptname = %dname return count($i/employees)";
   XQPreparedExpression expr = con,preparedExpression(xqry);
 
   // bind variable with value
   expr.bindString(new Qname("dname"), "engineering");
 
   // execute the XQuery Expression
   XQResultSequence rs = expr.executeQuery();
 
   // Consume results
   while (rs.next())
   {
     System.out.printLn(rs.getInt());
   }
 
   // clean up resources
   rs.close();
   con.close();
   

In the preceding code, XQDataSource is an interface from which you obtain XQuery connections. You can create the initial implementation class for the XQDataSource interface via a typical data source instantiation mechanism, such as JNDI look up or an explicit class-loading method. This is similar to the design of JDBC's DataSource and Connection interfaces.

After obtaining an XQConnection, you execute the XQuery using either the XQExpression or XQPreparedExpression interfaces. You'd use XQExpression when you want to execute an XQuery expression once, and XQPreparedExpression when you want to prepare the XQuery expression once and execute it multiple times with different bind values, as illustrated in the preceding example. These two interfaces are similar to the concepts of Statement and PreparedStatement in JDBC, respectively.

An XQuery result is an instance of the XQuery data model. The XQResultSequence shown in the example provides a cursor-centric interface that allows users to iterate through each item in the result sequence. Users can obtain values from each item, either atomic values or XML nodes. This is similar to iterating through a JDBC result set.

After consuming the XQuery results, developers need to clean up the resources by calling the close() method on the XQResultSequence and XQConnection interfaces. Proper error-handling code for releasing resources is critical to avoid resource leakage. The framework implicitly closes items created from the sequence result when the sequence result is closed. Similarly, the sequence result is implicitly closed if the connection is closed.