ProfKyne writes 'I was excited to read this book when I first noticed it listed as 'coming soon' in the of O'Reilly's site back in May. I downloaded and read the sample chapter and waited expectantly for the book to be released. I was hoping that this book would be perfect for me, as nearly all of the Java programming I have done has dealt in some way with database access, though I do not consider myself to be an expert on the subject.
The book didn't disappoint; Java Database Best Practices is an excellent high-level guide to writing database-driven applications from Java.' My take is that it depends on the app and your goals. C/C is generally faster and you get access to more in-depth APIs, at least with Oracle. Java through JDBC is easier to port to different databases and and platforms. JDBC has what I consider to be an advantage in that a lot of database drivers have 'thin-client' implementations which means no additional client-side installs. However, almost all the work I've done with JDBC was for server side apps, typically accessing data through app server connection. I tend to be a database snob, but just about any language that access the database gets its main power from the database.
I personally have never seen much difference between accessing a database with Java, C, PHP, PL/SQL, Visual Basic. Almost all of the programs are dependent on how well you design the database and the code pretty much follows from the relations with in the data.Java, of course, is the best language because it was developed with an overall higher level of coolness. It has like this oneness with the world thing going on.
C goes faster. Visual Basic and PHP are easier for beginnning programmers. Still, ti seems to me that relations within the data are the key to database integration happiness. Just about any language can gets its power from a database, but only as long as it's well programmed. Never underestimate the power of sloppy design, sloppy coding, lack of clue, or (my all time favourite) including useless buzzword technologies just because they're the latest hype with clueless managers.Yes, if you do a solid database design, and a solid program design which uses said database efficiently, in just about any language you can be as efficient as the database allows you to.However, you'd be. Well, I wrote a VB app that did this, so I know it is possible. ADO is pretty database-agnostic (although there are some special SQL server techniques).
I've personally written an app which just had an ODBC source setup with the common name using OLEDB provider for ODBC. It could use just about any relational db with an OLE db driver. I personally supported customers who used Pervasive SQL, SQL Server, an old Oracle version, and Access (ugh!).I did have to use connection.supports to do a few tests at run. There are many good and valid reasons to use Java, though they don't apply to everyone. For instance, Java is object-orientated which I understand makes code reuse better, I'm guessing because it makes Java plug-n-play.
Also, Java has strong datatyping, unlike C, so if you are typing data then you want to use Java. And I think there are Web server modules that let you use Java on a webpage, which improves site usability.In short, please try to think before you make rash claims about how lame Java is. I always had a problem with APIs doing locking and transaction control.If your application really requires these things, you might want to get a database server that has direct support for them and write them as stored procedures. Straight SQL stored procedures can be very powerful, and can keep a lot of this messy logic where it belongs on the database server. Transactions should be short and simple as well.Having a hanging transaction is one of a DBAs worst nightmares.I think for the most part client/server applications are loosing ground to more of a three tier application scheme.
In this case the cursor or the scrollable result set should be dumped, and instead just scroll through once and dump into a two dimensional array and access them this way. Multi-tiered applications still require database code, database locking, and data sharing.
While the client does not have access to a cursor or 'scrollable result set', those features are still used at the back end where the system interfaces to the persistant storage (RDBMS.) Caching them as an array is only viable if the data is stable during your application's execution (lookups), or if your application is the only one accessing the database.I agree that using application code to implement locking o. I was going to just mod you down, but I couldn't find the 'crazy' mod.In years of working with databases (mostly Oracle) I've yet to have a problem with Java, locking, and transaction control.What can happen is you forget to close a connection - but that's just poor coding. Going though the relatively extreme agony of defining a bunch of stored procedures instead of making people using 'finally' for close statements just makes no sense - at least for Java.
The JDBC API is very mature, and as someone e. One other advantage of stored procedures is that they are easier to deploy in a production environment since a server restart is usually not required. However I dislike using stored procedures (in Oracle, anyway) for several practical reasons:1. The syntax for stored procedures is awful. I always wondered where the hell they stole their syntax until I finally ran across some COBOL.2. The compiler and runtime error checking are poor.
The compiler generally stops at the first error it sees, and it does. Ask anybody who has done this and they will tell you what a bad idea it is.Putting business logic into the database is a tarpit which will doom your application.No unit testing, no way to organize your code into discrete files, no compiler to check the sanity of your entire codebase, no object oriented features (for MSSQL anyway), basically crappy SP languages.
It goes on and on.Having said that most non microsoft databases support java as an SP language and that mitigates a lot of my objections. I was excited to read this book when I first noticed it listed as 'coming soon' in the Java section of O'Reilly's site back in May. I downloaded and read the sample chapter and waited expectantly for the book to be released. I was hoping that this book would be perfect for me, as nearly all of the Java programming I have done has dealt in some way with database access, though I do not consider myself to be an expert on the subject.I was excited to read this title when I first noticed it listed on the Slashdot site soon after lunch. I downloaded and read the first couple paragraphs and waited expectantly for the material to seep through.
I was hoping that this article would be perfect for me to post an insightful reply on as nearly all of morning, I have been feeling dull and stupid. Though I am usually not so.Anyway, I don't think it's working. How many people out there use java in their web based apps that interface with a database server backend?My teams doWhat platforms do you use for development?WindowsWhat Dbs do you use?MSSQLWhat web server?Apache/TomcatWhy?Because all of our server side programs are written in Java.
Java Database Best Practices Pdf Download Pdf
We deploy to both windows and Linux, Java has increased our productivity over C, performance is on par with C for our systems (sometimes slower, sometimes faster), it means we have one technology for web and progra. How many people out there use java in their web based apps that interface with a database server backend?I would bet that nearly all the use of Java is for web-based apps that interface to a database.What platforms do you use for development?For Java, it would be J2SE from Sun (it includes JDBC).What Dbs do you use?Oracle, MySQL, PostgreSQL, DB2, etc.What web server?Apache, WebLogic, Sun ONE, etc.These questions, at face value, mainly answer themselves. Perhaps a better question would be: what do Java programmers do to prevent database applications from turning into a quagmire of naive mistakes and bottlenecks making a well-intentioned application into a sick joke of engineering?Database programming is one of those things that is simple enough, at first glance, to be attempted by every college sophomore on the planet, but complex enough, in reality, to make people who hired those college sophomores look foolish. Platform doesn't matter much. Linux, Win32, AIX, Solaris - they've all got decent Java IDEs and JDKs.Databases just need to be full-featured. Sybase, DB/2, Oracle, PostgreSQL - I don't care as long as it's got a full feature set including sequencers, triggers, and stored procs (in that order of usefulness.)Web servers are irrelevant to the back end development.
The web server has hooks that redirect certain pages or page types to the 'rich' environment of a J2EE or equivalent framework. Even Apache doesn't embed Tomcat, but cooperates with it to share the duties (let Apache do what it does best - server up simple content, and let Tomcat/J2EE/JSP do what it does best - serve up functionality with a corresponding performance hit.). I'm using Java for a data warehouse web app (which is somewhat different from the usual database app, because there aren't significant amounts of data going in through the application). We develop on Linux and Windows and will deploy on Linux. We're using Oracle and Tomcat.We're using Java mainly because we used it for a previous project and it worked well; switching to a different language, including evaluating, leaning, and determining good practices would not be worthwhile.
We're using Oracle and Tomcat. Solaris.The problem with Apache 1.3 is that each connection requires a separate instance of the child process, which in turn takes up 2 megs (or so) of memory. Multiply that by 500 concurrent clients, and you see the bottleneck right there.With 2.0 in MPM mode, each process (which we have configured to take 250 threads/children) takes up about 30-40 megs of memory. 500 concurrent clients takes up 80 megs of memory, as opposed to the 1 gig of memory with Apache 1.3.So the issue isn't that multithread.
Apache 2.0 in 'worker' MPM mode. Multi-threaded, multi-process.
Provides the stability of Apache 1.3 (multi-process so if one process crashes, no problem, they just get started right back up) along with a huge speed increase due to the multithreading. Changing from Apache 1.3 to Apache 2.0 in worker mode, tuned correctly, will give you a 500% capacity and speed boost, easily. We have gone from approximately 85 simultaneous connections max, running at about 200 requests per second, to over 2500 simultaneous. Just curious - does performance of Apache really matter, i.e. Wouldn't you reach the capacity of your app server (Resin in this case) way before you reach any limit of Apache?Nope. Think about this- say you have a page that is made up of:- 1 JSP page- 1 CSS file- 1 JS file- 7 images90% of your content is static, and can therefore be served up by Apache. Even by limiting Resin's threads to 250 simultaneous, you can safely set Apache up to handle 2500 concurrent requests, realizing that 90% of tho.
'yet we dropped WebLogic in favor of Tomcat due to horrible performance.' If all you're doing is XSL transformations, Weblogic shouldn't be any slower than Tomcat if you're using the same XSL parser. That said, I understand the memory/services overhead that Weblogic has. If you aren't doing EJB, Weblogic is serious overkill.This may sound like a bad pitch/endorsement, but you may want to consider switching from Tomcat to Resin. Resin provides all the same functionality that Tomcat does, and is quite a. Disclaimer: I am the author of the book being reviewed.I have never quite figured out why some developers have a visceral negative reaction to the expression 'best practices'. In any field, a best practice is nothing more than a rule of thumb that guides your decision making.
It is a heuristic.Best practices cannot be fully incorporated into a language. Java does a good job of that, but new best practices grow from further use. As the reviewer noted, the chapters on newer technologies (e.g. JDO) were lighter in this book because programmers simply have not had as much experience in developing best practices with those technologies as with older ones (e.g.
JDBC).Furthermore, a best practice is not something you get sent to the electric chair for violating. When your decision violates a best practice, the 'best practice' status simply indicates that you need to understand why it is a best practice and make sure you go to great lengths to justify its violation. On the other hand, you do not need to think a lot about sticking with a best practice.By leveraging best practices, you simply gain a short-cut in decision-making. For those people who would say 'short-cuts in decision making are bad', get real. Short cuts are necessary. You cannot analyze all possibilities resulting from every decision you make.
Otherwise, you would never manage to flip a switch to turn on a light bulb. Thanks for the thoughtful response.I think a lot of us react negatively because Best Practices are often pushed by architect types that don't write code but they have all the Best Practice books and they use those to evaluate your output. In other words, they can be used as a crutch for the unknowledgable.Also, there are the questions of 'just who decided that these were the Best Practices anyway?' And 'What exactly about them makes them Best?'
Those are questions that aren't usually answered before th. I think the greater problem with hearing 'best practices' from the Java crowd is that they keep changing them.Also, a lot of these 'best prctices' are pushed out by Sun's marketing well before any sort of performance is up to par.And finally, if people were really capable of following 'best practices' why the hell did Java have to be dumbed down to the lowest common denominator? If we assume people can code to 'best practices' then Java would never have come about. That's its chief selling point, you ca.
Every language, not just Java, has best practices. In fact, every thing-from using scissors (don't run with them) to playing right field (play to your right when a right-handed batter is at the plate)-has best practices.And best practices are always evolving.
Many past best practices for Java are no longer best practices because Java has changed. Sometimes best practices help you get around a flaw in the underlying tool (like closing result sets and statements in JDBC code). Those best practices eventua. The junior and intermediate developers need 'best practices' as a guideline while they learn. The experienced developer knows when to step out of the 'best practices' to get performance and features that are needed by the application.Think of it as driving a car.
Most people will never need nor experience the handling of performance car - the 'best practices' of a normal powertrain and suspension are all they need. That doesn't mean there aren't people out there who will make good use of the extra fu.
Probably because that's what the authors are learning, and that's the hot topics. 8 years ago, c classes were teaching how to code all types of lists. I guess because that's what people did a lot. That or so the people who used the lists had some notion of what a list is and what it does.the only reason that someone today would write a list class in java or in c or any other oo language is that they really need something specific or they don't understand the power of using tested code. Implementing a sequencer at the application level (one of the 'best practices') is a much better idea if you're not clustering your application servers and other applications will not be performing INSERTs into the database.Actually, with some slight transactional modifications, it can be used in a clustered environment as designed. It was, in fact, originally designed to support a clustered pre-EJB application.
I made the transaction support for the sake of this book simpler to illustrate the point.The key to this scheme is that each application gets its own sequence key, so multiple applications or cluster nodes are free to generate unique IDs without duplication by other nodes or applications.I myself have recently run into the problem of different sequencing systems on different databases (such as MySQL's AUTOINCREMENT column type vs PostgreSQL's sequence types). I've worked around it by modifying the application's database calls, but that isn't really a good strategy. Implementing a sequencer at the application level (one of the 'best practices') is a much better idea.I disagree. Why do you want to reimplement database features such as sequences when the developers of MySQL, PostgreSQL, Oracle, Sybase, etc.
Have spent plenty of time optimizing it. Ask Tom Kyte (of Oracle) his opinion about doing something like that - oracle.com.' But,' you say, 'that will mean making different versions of my code for each different database.' Take a look at the implementation of sourceforge.net which uses classes such as OracleDialect and MySQLDialect which are subclasses of Dialect. Each of these specific dialects implements vendor-specific code for sequences (and others). This allows the application level code to maintain its database independence while at the same time taking advantage of the vendor-specific features.Doug.
Application sequencers are the correct approach. You use as the only supporting evidence behind your claim that 'Application level sequence BAD':Ask Tom Kyte (of Oracle) his opinion about doing something like thatIn that article, Tom talks about a specific kind of application-level sequencer. The sequence he talks about is, in fact, a bad sequencer. When implementing an application-level sequencer, you must take into account the following:. Generated IDs must be guaranteed to be unique. The act of. That page gave an example of a bad way to do it.
There are also good ways to do it. I'm sure there are many implementations of things similar to my spy.net.This provides application level sequences in a cluster and bypasses a lot of performance issues. Combined with my hierarchial storage model, it allows us to build out large complex trees of objects where the objects all know the primary keys of all of the objects as they will be if they get stored in the DB. The framework also allows us to ensure the. I'm currently working on an article about an easy way to generate all the base classes you need for persistence. It's a lot of repetitative work to build that interface layer between SQL and target language.The basic idea is that one converts SQL into XML, then applies and XSLT to generate all the base classes.
I've applied this idea to three projects now, and I've gotten to where the autogenerator handles things like intersects properly.So if you get it right in the XSL, one can change the SQL structure. I read the chapter that was available on the website in PDF form and best practive my a.!When you talk about best practice, you could at least mention the best of them all, esp with databases like Oracle, use of bindvariables.The book gives examples in the form of:select blah from tableblah where bleh='WHATEVER';Everyone with some experience from an enterprise database knows the rule is: 'Parse once, execute many times'. By replacing 'WHATEVER' with:bindvariable and assign WHATEVER to:bindvariable. Except the example chapter is about database architecture and not database programming. And it comes in the book before I have introduced the concept of bind variables (aka callable statements) or stored procedures. Thus, it is:a) Not a best practice in database architecture, so inappropriate to call out as a best practice at that pointb) Too complex a concept to assume knowledge of at that point in the bookAs a side note, I do call this out as a best practice in a later chapter and all subsequent chap. Because something is not a best practice does not make it a 'worst practice'.
Bind variables are actually very difficult things when you first encounter them-especially if accompanied with no explanation.On the other hand, in simple SQL examples demonstrating join tables outside the context of any higher level programming language, the use of bind variables is completely inappropriate.Though you may think I am not taking criticism well, I am simply pointing out that you and the previous poster are look. It might just be me having a bad day, but a usual I react with a vaulting wave of sheer loathing upon hearing the phrase 'Best Practices'. Try Over-Sensitized!In my experience the only people who use such terms are mediocre Sales & Marketing managers who are supreme bullshitters and such phrases are the way they get this bullshit propogated.
Then since they really do not have a clue about things like security, reliability, robustness, risk management, or engineering, nor real success at. Don't talk about 'Best Practices', talk about the real issues: Security, Reliability, Robustness.Let's see: Security. The biggest issue in security is generally the people.how they define passwords, what things they let go through firewalls, what things they should and shouldn't do. The security expert cannot completely make a network safe.they must define a best practices and go from there.Reliability: I may be totally off base, but it seems to me that consistency is a factor in reliability. Assuring that things are written in a consistent manner generally involves defining best practices.
I have seen many programs fail because a coder used inconsistent naming conventions.Likewise Robustness seems to follow from having defined best practices. 'Best Practices' is yet another ridiculous business term that is crossing over into the IT world.It does have a little meaning. Best practices are basically what a person would do after spending some time thinking about what would be an elegant way to solve a problem.Best practices are not achieved after one 30-minute meeting.
Nor are they achievable by design-by-committee. They require people on a team to be honest, first, and political, last.Unfortunately, this rarely occurs in the real world, espe. Maybe instead of 'Best Practices' we can come up with a new term or two:HBUY (Haven't Blown Up Yet) PracticesWNRSWTW (We're Not Really Sure Why They Work) PracticesDSABAATO (Doesn't Suck As Bad As All The Others) PracticesI think the idea of 'Best Practices' really does aim at security, reliability, and robustness. The idea is that someone/some group has found a set of methods that seems to work quite well in regard to these.
So, let's use these as the baseline and improve from their instead of creating. This is the only way to develop robust, stable, secure, scalable, and maintainable software. Without this, there can clearly be no quality within the final product. Having several independent methodologies / best practices is simply unacceptable and goes against all common sense and logic.At my company we adhere to such a methodology and have delivered software that eventually compiled - every time.With that, I'd like to introduce our unified methodology and propose that it be given proper respect thr.