Per, thanks for your response -- it has just challenged me to think
that perhaps my whole understanding is drastically broken.  As such,
I'll toss out a few assumptions; please, anyone, feel free to correct
me.

Beans, as I understand them, are units of code inside a EJB
container.  I'm roughly aware there is a particular type of bean used
for persistence of data.  It was my understanding that in order to do
this, correctly, certain conventions needed to be followed.  And, in
the ideal case, something like Hibernate is a fantastic solution.

However, in my current case, we have little control over the actual
database -- it's got all kinds of wacky joins, views, stored
procedures, constraints, and is frequently being modified by other
external systems... there's custom stuff Hibernate just couldn't know
about; consequently, we actually don't have objects we're trying to
persist, but rather are just trying to get in, execute some SQL, and
get back out in the shortest period of time.

So, am I using a bean to do the persisting for me... no. Is the code
thread inside of a bean when I'm trying to access the database...
yes.

Paralleling plain old JDBC, my thought was literally to get the
context, get the datasource, and obtain a connection like this:
 Context ic = new InitialContext();
 DataSource ds = ( DataSource ) ic.lookup( datasource_name );
 Connection conn = ds.getConnection();

And, this seems to work.  However, conn.commit() doesn't work.  It
feels like I'm not really getting a connection, but a transaction.
"But why do the above in the first place?" you may be thinking.  The
overhead of straight JDBC was slow, if JBoss has a connection pool
available that I can borrow from, the speed increase is well worth
it.  Additionally, my SQL statement is to call a stored procedure, not
persist an object in memory.

What has me thinking, based on your response is the UserTransaction
and SessionContext.  I haven't run across those yet.  And your
mentioning that connection pooling is a container concept adds
additional doubt that perhaps I'm doing something very wrong, perhaps
touching JBoss internals that have no business playing with.

Does that help clarify the details?

-Walt Stoneburner
wls@wwco.com