Re: [JBoss-dev] ditch entity locking in favor of select-for-update
isn't SELECT FOR UPDATE an Oracle-ism? instead of either entity locking or S-F-U, why not use an optimistic concurrency scheme, with verified updates? there was recently a nice catfight on the EJB-INTEREST mailing list between several vendors on this subject, the result of which seemed to be that this would be the approach which maximized both performance and portability. -- joe ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] new wait(1000) not good
Georg == Georg Rehfeld [EMAIL PROTECTED] writes: Georg notifyAll seems to be MUCH better as of the docs: Georg | The awakened threads will compete in the usual manner with | Georg any other threads that might be actively competing to | Georg synchronize on this object; for example, the awakened threads Georg | enjoy no reliable privilege or disadvantage in being the Georg next | thread to lock this object. Georg So every thread, if it was waiting before or just coming in Georg fresh, has the same chance to get the lock and proceed, Georg avoiding starvation. this is not implied by the snippet you posted. all it says is that the threads in the wait set will compete in the usual manner, which is no more fully specified than the case with notify(). no scheduling method is implied in either notify() or notifyAll(), so you can make no guarantees of fairness. also, notifyAll() can lead to the so-called 'thundreing herd' of threads waking, competing for the lock, and (all but one) going back to sleep again. that said, any quality JVM will implement some sort of quasi-fair scheduling policy, so it's not likely to lead to starvation. but if you really want fairness, you cannot rely on the builtins. there is a excellent discussion of this, and some examples on writing a FIFO scheduler, in Doug Lea's 'Concurrent Programming in Java, 2nd Ed', which I recommend highly. -- joe ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Reason for abstract methods in jboss-j2ee
Jesper == Jesper Pedersen [EMAIL PROTECTED] writes: Jesper You can say that methods in an interface are abstract, since Jesper the interface doesn't contain an implementation. Jesper But I see no reason for declaring them abstract, since the Jesper abstract keyword only has meaning when used in a class Jesper definition. Jesper Sun doesn't declare methods in the interfaces abstract -- Jesper check the Javadoc generated from EJB 2.0 PFD2 compared to Jesper jboss-j2ee. JLS 9.4: For compatibility with older versions of Java, it is permitted but discouraged, as a matter of style, to redundantly specify the _abstract_ modifier for methods declared in interfaces. -- joe ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic
on a related note, can someone comment on dynaimc code downloading problem and the proposed solution? I just recently started checking out JBoss, and have generally been impressed. but the fact that dynamic downloading just plain doesn't work is really, *really*, unfortunate. -- joe ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
