Your JDBC URL syntax is wrong.

You need something like jdbc:oracle:oci:@RPTD

java.lang.UnsatisfiedLinkError: free_c_statejava.lang.UnsatisfiedLinkError: free_c_state
at oracle.jdbc.oci8.OCIDBAccess.logoff(OCIDBAccess.java:616)
at oracle.jdbc.driver.OracleConnection.(OracleConnection.java:409)
at oracle.jdbc.driver.OracleDriver.getConnectionInstance(OracleDriver.java:468)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:314)
...

• JBoss useer: 50%
• Glassfish: 0%
• Websphere: didn’t ask!

The thrust of the talk: take a typical Java EE 5 application (JavaServer Faces -> managed session bean -> entity class -> database) and refactor it to Seam. This is interesting, but we don’t even have any Java EE 5 web apps to refactor, so both the Java EE and the Seam stuff are new to me.

Java EE: lots of config and the syntax looks nasty after Ruby, though a big improvement over J2EE of years past, for sure.

EJB 3 and EE5

• Dramatic simplification of all bean types
• POJOs + annotations
• Dependency injection

You know, I looked around at the audience at this point, and noticed that the room full of big, dumb-looking people. Not a good sign.

OK, here’s what I learned.

JBoss Seam is an application framework for JSF and EJB; it brings them together. Must be good: it has AJAX! Also has improved state management. The presenter showed this at the end and, yeah, this is good.

Seam eliminates the managed bean, reduces the XML and provides “bijection” for stateful components: dynamic, contextual, bidirectional. What? Yeah, I couldn’t figure it out either.

We get a live demo where the presenter troubleshoots various problems. Never a good idea to expect that you’ll work through issues live in presentation. Buzz kill for the audience.

Ahhh, a choice J2EE moment. The framework needs a blank property file, but if it’s not there, you get a cryptic error message that doesn’t mention property files.

We see pattern-matching to look up EJBs. Can’t recall now if that’s Java EE or Seam.

Seam replaces XML with annotations. Good. The more annotations the better I think. Looks like you can inject dependencies via annotations:
@In private User user;

Audience Pool

90% use CI
I’m the only one who doesn’t use CruiseControl, and the presenter wants to know what I do use. “Ruby” seems to be a worthy answer. Wheh.

There are several implementations of CruiseControl — Java, .Net, Ruby — and it can be customized plugins. This talk is actually about customizing CruiseControl.

The presenters use their own ThoughtWorks project as an example. It’s a big, old Java project with 8,000 class files. So, in the ballpark of the entire Con-way application, er, applications. It takes over thirty minutes to build and test. They have about 6,000 tests, and are slightly embarrassed by how light their test coverage is.

The central problems with their CI is the volume of information and correlating it together. They solved these problems with the practical application of brute force by using Lucene to index the CruiseControl build logs (this includes source control commit comments and bug tracking numbers). It has a simple web front-end, so there’s one place to figure out which bug is fixed in which build. It was initially for developers, but business analysts like it, too.

We had a nice chat about build lights (build broke, light goes red). Apparently, x10.com is the place to go to buy one. You may remember them from endless, annoying banner ads. Other sources:

• NaBazTag
• Ambient Orb
• Lava

I liked the presentation’s funky diagrams. Think Scooby Doo’s Mystery Machine van.

Suggestion: build a CI build dashboard on an old PC and monitor in your bullpen. Hey, the ARAOT is ahead of the curve!

Things started out just fine, with some rambling and ranting about how the open source software developer crowd is faddish. “XML is staid? I’m a graybeard because I work in XML? What?” Funny. True!

News flash: everything is more complicated now, mainly because we aren’t just running on a disconnected box under the desk.

Halfway through the talk, though, the presenter is still ranting! Wait, the point? Maybe we need to simplify the models we use to combat complexity.

• Web enforces simplicity
• Traditional mid-tier apps break down on the web because they assume synchronous interactions
• Simplest arch pattern is an old one — MVC

Ten minutes later, a question from the audience: are we going to talk about XQuery? Oh, yeah, OK.

There are many emerging XML standards:

• XHTML + XForms
• XSLT
• XQuery
• Schematron
• XBL

XForms started as replacement for HTML forms, but became more. They create an XML model that uses XPath to “bind” control to various parts of model. XForm is sort of like a VB form. Did you just cringe? I did.

XForm implementations to watch

• Mozilla (presenter’s favorite)
• Orbeon
• Chiba
• Formsplayer
• PicoForm
• OpenOffice

Maybe XForms will be the Next Big Thing, but I’m not holding my breath.

Here’s our audience poll:
95% use DB apps
15% are consultants (like the presenter)

Clients just say: “the database is slow,” but anything in the big application stack (application, middleware, database, operating system, hardware_ can make things slow. Every layer in the stack needs do its job to scale the application. Otherwise, we are leaving significant performance gains on the table. In fact, “database” problems are usually somewhere else — like in the middleware.

You have many performance problems in your application, but most aren’t significant. Performance is usually degraded by a few problems — 10% of problems cause 90% of slowdown. (And big problems mask smaller problems.)

Apps tune differently. The presenter uses three rough categories: web, online transaction processing, data warehouse.
Web

• Entire database can fit in RAM
• 90% or more of database queries are simple reads
• CPU-bound
• Performance moles: caching, pooling, connection time

OLTP

• Database slightly larger than RAM to 1TB
• Many small data write queries
• CPU or I/O bound
• Moles: locks, cache, transactions, write speed, log

Data Warehouse

• 100GB to 100TB database
• Large complex reporting queris
• Large bulk loads of data
• Also called “business intelligence”
• Moles: Sequential scans, resources, bad queries

Your first step should be to measure a baseline. Check basic setup (versions, configurations) for sanity. Then measure each layer.

Tools

• OS tools are simple, easy to use, and non-invasive
• ps, mpstat
• Benchmark. Invasive
• micorbenchmarkL bonnie++ for files system perf
• DB
• DBTrace
• DB query log
• Query analysis (troublehoot “bad” queries)
• ogbench, Wisconsin, TPCB, OSDB, PolePosition
• Application
• app server tools
• workload simulation and screen scraping
• lwp and log replay tools

• bug detectors

• valgrind, MDB, GDB, DTrace

OK, we’ve got the baseline, now what? What are the symptoms; when do they occur?

The Performance Moles

I/O

• Symptoms: one device saturating I/O — other resources are OK
• heavy writes or very large DB
• causes
• bad I/O hardware, software or configuration
• not enough RAM
• too much data requested
• bad schema

CPU

• Symptoms: maxed-out CPU, but RAM available
• mostly-read loads or complex calculations
• causes
• too many queries
• insufficient caching or pooling
• too much data requested
• bad queries or schema
• Note: most DB servers should be CPU-bound at max load

Locking Mole

• Symptoms: Resource aren’t maxed-out
• lots of pessimistic locking
• causes
• long-running transaction or stored procedures
• longly held open cursors
• unneeded pessimistic locking
• poor transaction management

App Mole

• Symptoms: DB server maxed, app server is OK
• common in J2EE
• causes
• not enough app servers
• too much data/ too many queries
• bad caching.pooling
• driver issues
• ORM frameworks