Cluster wide lock

Discussions

EJB design: Cluster wide lock

  1. Cluster wide lock (8 messages)

    Hi,
    In my weblogic 8.1 j2ee application, a team of users can create one record. But, that record should be created only once. In a clustered environment, if 2 team members decide to create the record at the same time, one of them should fail. Please correct me, if i am wrong about this: Isolation level serializable at entity bean level would not work at bean level in a clustered environment, because each server in a cluster will just make sure that the record is created in serializable fashion, it would not prevent 2 threads entering into the same entity bean at the same time in 2 different jvms.
    So, if the above statement is correct, i need a lock which would prevent concurrent access in 2 different jvms to 2 instances of same entity , one in each jvm. Double checked locking wouldnt work either. I can probably do the update via rmi.. but that sounds very unorthodox. Is there a cluster wide lock available?

    Threaded Messages (8)

  2. Cluster wide lock[ Go to top ]

    Hi,

    Normally in clustered environment only one server instance acts as a GroupLeader, that member will instruct the other member servers to updates their databases..i believe this kind of solution works.
  3. Cluster wide lock[ Go to top ]

    Hi,

    If you want a cluster wide lock, you should put it in the common access point: the database.


    Best regards, Mircea
  4. group leader[ Go to top ]

    In weblogic cluster, i believe in any homogeneous cluster running j2ee app, all the servers carry an active copy of the same entity. Thus, any server can update the db...., what i want is a lock which any server in the cluster should look if it exists. Actually JNDI can probably help in this case. I am not sure if this possible, but if it is, any server can create a lock and bind it with jndi if that lock does not exist. then any other server which tries to create a record , should look for that lock in jndi..
  5. group leader[ Go to top ]

    In weblogic cluster, i believe in any homogeneous cluster running j2ee app, all the servers carry an active copy of the same entity. Thus, any server can update the db...., what i want is a lock which any server in the cluster should look if it exists. Actually JNDI can probably help in this case. I am not sure if this possible, but if it is, any server can create a lock and bind it with jndi if that lock does not exist. then any other server which tries to create a record , should look for that lock in jndi..
  6. Database lock[ Go to top ]

    Database lock sounds like a good solution. Unfortunately,
    it will probably not work for my problem, because our database runs on Oracle RAC(real application cluster).. Maybe oracle provides a cluster wide lock for their database cluster...., but i agree with you, the solution will definately lie on database side.
    Thanks :-)
  7. why not try db constraints[ Go to top ]

    Have you thought about db constraints. You do not seem to have a locking issue. There is no difference between your problem (as i see it) and the standard two people try to create a new "user" record. If you can have multiple servers or entry points to the db then why is clustering a big deal. If I create user Joe and you create user Joe then we stop the second attempt via a db constraint, i.e. login name must be unique. One method to allow a single record is to id records (via a name for example) and then put a constraint on that field in the db. The names can be your app names or module names or whatever. This is pretty similia to jndi, i.e. you make the name unique at the db level just like jndi makes its paths unique.

    Just my 2 cents.

    Bruce
  8. unique index[ Go to top ]

    If i create a unique index on first name, last name and addresss. (An SSN would have worked, but we dont accept those.) An index like this would be heavy in terms of performance when deletes or updates are made. I am not sure about the constraint costs on the insert operation when table grows large..... or the maintenance and growth issues of such an index. We do use unique index on single column basis to handle similar subset of problems.
  9. Where do you get this. Unique indexes have overhead. But you would rather have a clusterwide notification policy instead. Lets think it through the db is designed to handle unique indexes with a relatively good performance trade-off, i.e. it is already tuned by oracle or whoever. I would think thats going to be way more efficient than rolling your own solution here with cluster wide locks.

    I think you are thinking too much about this problem. You NEED correct db unique contraints anyway. If anyone updates your db besides you which will normally happen in more production servers then the db contraints will still protect the db integrity.

    Heres another thought. If you are worried about performance why not create a test program and throw a million or so records into your db. Test with and without the contraint and see for yourself if the overhead is too high. But I would do this BEFORE you start rolling your own solution here.

    Hope this helps.

    Bruce