How to delete records in join sql query in oracle.

2.
How to delete records in join sql query in oracle.

DELETE
      from role_resource_privilege
      where exists (select rrp.*
      FROM role_resource_privilege rrp
      LEFT JOIN role r
      ON r.role_id = rrp.role_id
      LEFT JOIN resource_privilege rp
      ON rp.resource_id     = rrp.resource_id
      AND rp.privilege_id   = rrp.privilege_id
      where rp.resource_id is null
      OR r.role_id         IS NULL); 

ORA-01779: cannot modify a column which maps to a non key-preserved table

Oracle issue :
------------------
ORA-01779: cannot modify a column which maps to a non key-preserved table

Reason : 


      update (
      select ur.sysadmin FROM user_role ur
      INNER JOIN user_profile up
      ON up.user_id = ur.user_id
      INNER JOIN role r
      ON r.role_id      = ur.role_id
      WHERE ur.sysadmin = 1
      and ( up.sysadmin = 0
      or r.sysadmin     = 0 )) t
      SET t.sysadmin = 0;
   
   Because inline view returns 0 rows and oracle could figure out records to be updated.
   
Solution :
  
   update user_role usr set usr.sysadmin = 0
      where exists (
      select ur.* FROM user_role ur
      INNER JOIN user_profile up
      ON up.user_id = ur.user_id
      INNER JOIN role r
      ON r.role_id      = ur.role_id
      WHERE ur.sysadmin = 1
      and ( up.sysadmin = 0
      or r.sysadmin     = 0 ));
   
We can also use merge statement to update rows in join

          merge INTO resource_master c USING resource_master p ON (p.resource_id = c.parent_id)
        WHEN matched THEN
          UPDATE SET c.active = 0;   

Why do we need 64 bit JVM

Why do we need 64 bit JVM:
----------------------------
The primary reason would be if you wanted to write an app capable of using a large amount of memory (e.g. over 4GB, or whatever the per-process limit on your operating system is).
1. When we need to handle more memory ptentially more than 4G.
2. Note, however, that due to the larger adresses (32-bit is 4 bytes, 64-bit is 8 bytes) a 64-bit JVM will require more memory than a 32-bit JVM for the same task.
3. The Java compiler produces byte code which is same whether you use the 32-bit or 64-bit JDK and plan to use the 32-bit or 64-bit JRE.
4. One way to use a 64-bit JVM efficiently is to use the -XX:+UseCompressedOops which uses 32-bit references in a way which can still access 32 GB of memory. It can do this because every object in the Sun/Oracle JVM is allocated on a 8-byte boundary (i.e. the lower 3 bits of the address are 000) By shifting the bits of the 32-bit reference, it can access 4GB * 8 or 32 GB in total. It has been suggested that this should be the default for Java 7.
Support for 32-bit programs
Programs written and compiled for a 32-bit JVM will work without re-compilation. However any native libraries used will not. A 64-bit JVM can only load 64-bit native libraries.
http://software.intel.com/en-us/blogs/2011/07/07/all-about-64-bit-programming-in-one-place/
http://java.dzone.com/articles/java-all-about-64-bit

Load balancer

Load Balancer

A load balancer in front of the cluster makes sure that all servers receive fair share of user requests. A hardware load balancer is usually a best option as it provides maximum performance. Companies such F5 and Cisco (big IP) are known for good hardware load balancers. If your budged cannot afford a hardware load balancer, an Apache server running a combination of mod_proxy, mod_rewrite and mod_redundancy can be another option.

Tangosol vs Terracotta

Terracotta DSO uses a TCP/IP-based client/server architecture that consists of client-side instrumentation (byte code changes for "transparent clustering"), combined with a central server ("hub") for sharing state between application servers. In a Coherence cluster, the analogous components would be our free Coherence Data Client on the application servers, combined with any of our server-side editions (e.g. Coherence Caching Edition) as a fault-tolerant scale-out solution for state and data management.

Terracotta explains their clustering as follows:


Terracotta servers can be deployed as an active-Primary plus a passive-Secondary (i.e. 1 or numerous hot-standby(s)) - the hot-standby shares disk with the primary Terracotta Server. On failure of the primary, client-JVMs transparently connect to the standby.


Any my response:

For reference, this is one of the primary differences betweent Terracotta clustering and Tangosol clustering. Terracotta can cluster two servers (one hot, one standby) while Tangosol can run a couple thousand servers as "hot" (active + active + active + etc) in an n-way fully-connected mesh (virtual channels). Our server throughput in a 100-server system is 50x that of a hot+hot 2-server system, and (in a fully switched fabric) our throughput in a 1000-server system is 10x that of a 100-server system. And failover time (automatic, without data loss or interruption of application flow) is still typically sub-second.

Regarding the connections between the application servers and the Terracotta server, it is a TCP/IP client/server connection (no fundamental differences at the wire level from a Telnet session, JDBC connection or RMI). It is analogous to our free Data Client or our low-cost Real-Time Client.

Speaking for me personally, I would evaluate plugging Terracotta in through the TCP/IP connectivity (ours, theirs, whatever), because Terracotta has focused on the programming model (AOP, Spring, etc.), and it could be a good addition for working with data in a Data Grid.

--From link : http://www.infoq.com/news/2006/12/terracotta-jvm-clustering

Low latency architecture

LMAX - How to Do 100K TPS at Less than 1ms Latency

Imp links :
http://martinfowler.com/articles/lmax.html
http://ftalphaville.ft.com/blog/2009/07/08/60761/the-cold-war-in-high-frequency-trading/
http://ftalphaville.ft.com/blog/tag/high-frequency-trading/

potential uses for dynamic proxies

1.Event publishing - on method x(), transparently call y() or send message z.
2.Transaction management (for db connections or other transactional ops)
3.Thread management - thread out expensive operations transparently.
4.Performance tracking - timing operations checked by a CountdownLatch, for example.
5.Connection management - thinking of APIs like Salesforce's Enterprise API that require clients of their service to start a session before executing any operations.
6.Changing method parameters - in case you want to pass default values for nulls, if that's your sort of thing.
Those are just a few options in addition to validation and logging like you've described above. FWIW, JSR 303, a bean validation specification, has an AOP-style implementation in Hibernate Validator, so you don't need to implement it for your data objects specifically. Spring framework also has validation built in and has really nice integration with AspectJ for some of the stuff described here.
7. Another useful side of a dynamic proxy is when you want to apply the same operation to all methods. With a static proxy you'd need a lot of duplicated code (on each proxied method you would need the same call to a method, and then delegate to the proxied object), and a dynamic proxy would minimize this.