Dariusz Kordonski

I am currently interested in the subject of persistent locking, i.e. acquiring locks in a database. Last year I was involved in several projects with such requirement, mainly on account of running in clustered environment. In such case there is sometimes a need to ensure that a resource / critical code block is subject to synchronized modification / execution beyond the scope of a single JVM. As far as I know, database vendors offer different kinds of locks, but they all are bound to a single transaction (this is also reflected by ORM APIs, which often provide lock() methods that are bound to current transaction). The usecases that I encountered required different scopes:

- 'smaller' than a single transaction (e.g. small block of code that required cluster-wide synchronization within larger transaction executed frequently - transaction-scoped lock would hurt scalability, since each transaction would be blocked at entry point to the critical code block until the one holding the lock would finish)
- 'greater' than a single transaction - e.g. possimistic locking of data objects for certain page flows consisting of multiple web pages (= requests = transactions) for current user. If another user tried to enter the page flow, he would be informed that someone else is modifying the data and he must try again later (this usually does not fit for mass-user internet portals, but does occur in internal entrprise apps)

I am trying to design a framework that would handle such use cases in a generic way, thus making implementation of this kind of locking easier. But I don't see much discussion around this particular topic (in fact, I don't see any discussion:) and I wonder, if I'm the only person out there that has met such use cases... Probably app server vendors provide their own solutions for cluster-wide locking, presumably in some more clever way than database, but the projects I participated in usually operated on simple, unmanaged clusters (actually 'cluster' is a wrong name for this, they were simple collections of machines hidden behind load-balancer). So this kind of solution (vendor-specific) was not an answer.

My question is therefore - have you ever met the kind of use case I described - where persistent locks would be useful? If so, please describe it. I don't want to do anything basing on exclusively on my experience. It would help me a lot to get to know various points of view and to convince myself that this kind of locking is useful in more scenarios.

What don't you understand? This specific overload or the whole concept of formatting strings? Formatting strings is a process of combining a string (called a 'format string') containing some special characters ('format specifiers') with a list of arguments, which gives a formatted string as output. The whole specification for formatting in Java is pretty long and somewhat complicated. You will probably find all details you need in the JavaDoc of the java.util.Formatter class.

As to the String#format using Locale, it just formats all locale-specific arguments provided to the method (date, time, numbers etc.) according to the given Locale.

A (very simple example of format:
int i = 6; System.out.printf("The value of 'i' is: %d", i);
The code above will output: The value of 'i' is: 6
(printf works same as String#format)
In this example:
"The value of 'i' is: %d" is a format string
%d is a fomat specifier for decimal integer
i is argument, whose value is substituted for %d
[ August 13, 2008: Message edited by: Dariusz Kordonski ]

Originally posted by Sachindra Pratap:
// ...

r_v[column] = new riu_voicecall_thread(column);
r_v[column].setPriority(8);
r_v[column].start();

r_t[column]=new riu_thread(create_RIU_cnt,column);
r_t[column].setPriority(8);
r_t[column].start();

r_c[column]= new riu_thred_connection(create_RIU_cnt,column);
r_c[column].start();

// ...


The query how much reliable is the block inside the function is
if function is called in very very less time interval.
And threads inside the function are also static.[/QB]

I guess the above part is the one you're worried about. Well... it is harmless You just start 3 threads from what I see. If you call this multiple times, more threads will simply be started. You must provide more details about your problem - how the implementation of the started threads looks like (e.g. 'riu_voicecall_thread' says nothing about what this thread does after starting; BTW it is better to define your own thread by implementing Runnable and passing it to java.lang.Thread during construction than to extend java.lang.Thread itself). Perhaps you mean that the above method is invoked asynchronously, by multiple threads?
The fact that your reference variables pointing to thread objects are static (not threads themselves, threads cannot be static) is not a problem, because with each invocation you assign a new thread object to them. If it is safe for the variables you pass to them (column, create_RIU_cnt) depends, again, on the things that they do with those variables (i.e. implementation of your threads).

I didn't quite understand your question. It would be simpler if you just posted your complete code and asked a specific question regarding it. You can use [CODE] markups for that.

Hash*** collections use hashCode() AND equals() methods of objects to determine if a given object is held within the collection. It is important to know that hashCode is only a 'pre-eliminary' check. Elements of a hash collection are stored in a kind of 'sub-collections', each of them labeled with a specific hash-value. The check, if a given object is held within a collection is performed in two steps:
1) hashCode of objects is retrieved and the collection checks if there is already a sub-collection marked with this hashCode; if not - the object is not in the collection, end of check process
2) if 1) holds true, the matching sub-collection is iterated and equals() invoked on each member until it returns true (object found) or the end of sub-collection is reached.

This procedure may significantly speed up the process of finding given object within a collection. And that's core reason of existence of the hashCode() method. But it requires each object held in the collection to reasonably override hashCode() and equals(). Moreover, there is a special contract between hashCode() and equals(): if o1.equals(o2) == true, then o1.hashCode() == o2.hashCode() (but it must work only in this direction, o1.hashCode() == o2.hashCode() does not have to imply o1.equals(o2). Think about it and find out whyyourself. You may find it useful to take a look at:
http://java.sun.com/javase/6/docs/api/java/lang/Object.html#hashCode()
http://java.sun.com/javase/6/docs/api/java/lang/Object.html#equals(java.lang.Object)
http://www.ibm.com/developerworks/java/library/j-jtp05273.html (a bit old, but does a good job in explaining equals and hashCode)

You're right Steve. More specifically, the issue arises, if you synchronize on the Thread object (I left the ThradB class extending thread, but refactored the code to synchronize on an instance of a separate class, not ThreadB - the code worked 'as it should' i.e. hanged). Probably bacause, as Steve explained, notifyAll() (or something similar) is called on a Thread object before the corresponding thread dies.

I'm afraid there is no such class in the Java API (at least I never heard of it ). There is java.util.Hashtable and java.util.concurrent.ConcurrentHashMap (which are quite similar, with the latter being a bit faster for some operations), but as far as I know, neither of them supports element ordering, which is one of Sreedhar's requirements.

Maneesh has explained your problem very well, just if you're courious why is it happenning - check out the Java Language Specification v3 $15.18.1.1
[ August 08, 2008: Message edited by: Dariusz Kordonski ]

If you need ordered key-value entries, then I think LHM it is simply the most natural choice for you (as far as Java is concerned). There may be some collection implementations that provide better performance, but frankly, I doubt it would be more than a marginal difference. One thing that might be significant in your case is that LHM is not synchronized. However, you may always use Collections#synchronizedMap() to enforce it. I looked in java.util.concurrent package, but haven't found ordered concurrent map implementation.

As I saw the code, I would say that it should make the application hang, because there are two threads calling wait() and only one call to notify(), so at least one thread should remain waiting forever... at least one, because there is a chance that notify runs before both calls to wait() (if 'Run' thread started by b instance gets the lock on this object first, it will execute the whole synchronized block, together with sleep() and notify, before main and Jack have a chance to call wait()).

But I run this code on my computer and it executed just as you said - as though the wait() calls were somehow ignored. I even started one additional Xyz-based thread, but it didn't change anything. Frankly speaking, I don't have any idea why. Either we overlook something very obvious, or the wait()/notify() don't behave as specified in the API
[ August 08, 2008: Message edited by: Dariusz Kordonski ]

Amardeep, check out: http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html . You will find some useful basic information on primitives that should help you undertsand the topic better. Regards

Theoretically, its 'singletonness' may be broken by defining class in the same package and setting b to null from within it. Make b either private or final to avoid it.

public interface xyz{

int a = 10;

}

Be aware that it is actually public static final int a. No fields other than public constants are allowed in interfaces. Even though the compiler will add those modifiers for you, it is a good practice to put them in code explicitly. Also, Java code conventions recommend to write constant fields names in uppercase, so A would be better then a

public class abc implements xyz{ int b=5; System.out.println(a+b); }

You try to put an execution statement ('System.out.println(a+b);') within a class body. It is not allowed, you have to define a method and put this statement into it, like this:
public class abc implements xyz{ int b=5; public void printSum() { System.out.println(a+b); } }

The statement'int b=5;', on the other hand, will compile, because it is so called initialization statement. It will be executed each time a new instance of your class abc is created (by the way - according to code conventions it would rather be Abc; I know that's just a simple example and I'm being overly scrupulous, but I found out that the more you stick to good practices - even in the simplest examples - the more you see them in your real-life code )


Ooops, Sagar responded quicker... and I gave away the secret :roll:
[ August 07, 2008: Message edited by: Dariusz Kordonski ]

cat []c=new cat[]; // this won't work, you have to specify size of the instantiated array, e.g. new cat[5];

my=my[0];
//can't assign a 1-D array to a 2-D array.


my=my[0][0];
//can't assign a nonarray object to a 2-D array reference.

my[1]=my[1][2];
//can't assign a nonarray object to a 1-D array reference.

my[0][1]=c;
//can't assign an array object to a nonarray reference my[0][1] can only refer to a cat object[/QB]

What specifically you don't understand? There is one simple rule here: n-dimensional array reference of object x can only refer to instance of exactly n-dimensional array of object x (or subclass of x, since arrays are polymorphic) - period. In your case, cat[][] instance cannot be assigned to cat[] reference and vice versa, and so on...

I guess one of the core reasons for its existence is String conversion defined in JLS (check out JLS v3 $15.18.1.1).