|
>> >> Wouldn't one or two nasty bugs be a sufficient teacher? >> >One or two nasty bugs ... did you ever have problems with deadlocks in >multithreaded applications??? Maybe that's my problem. I've been a developer of system programming for nearly 30 years, including the original single level store paging code. Needless to say, I have significant experience with such bugs both at the system and application level. Perhaps your suggestions are practical for your environment, but it seems very draconian to me. Java's synchronization is itself pretty draconian (and therefore simplified compared to what I deal with), which is why your responses surprise me. It's not like we're dealing with shared reads and all. Most bugs would be "I forgot to put 'synchronized' here," which ought to be easy to spot in code inspections or even DOS FIND commands on your code tree (looking for both "native" and "synchronized"). Not to mention that it is hardly a requirement for Java code to be multi-threaded to start with, though it may be prudent to make some allowance for it later on, I suppose. I haven't measured the performance here, but I would expect that a solution like stored procedures (at least when there's no real data base operation involved) could be done faster with data queues or sockets. I don't remember you mentioning that (perhaps you did). That solution, too, would alleviate concerns about synchronization. Larry W. Loen - Senior Linux, Java, and iSeries Performance Analyst Dept HP4, Rochester MN
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.