Win a copy of Learn Java with Math: Using Fun Projects and Games this week in the Beginning Java forum!

Jeff Wisard

Ranch Hand
+ Follow
since Jan 07, 2002
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jeff Wisard

Okay, I have a solution to the problem of getting a reference to the containers transaction manager. Here it is:

The only wildcard here is the string to send to the lookup method. What you see here is the string that is needed for Weblogic...and possibly other servers. This may be different dependent on the server and I intend to make it configurable.

I did this within a SLSB method and I my Synchronization implementation successfully recieved the message, so I'm good to go. Thanks a lot for your insight, Lars. You definitely pointed me in the right direction.

The only thing that I am not sure of is whether this is considered 'legal' in the context of a SLSB. Considering that the TransactionManager is not exposed from the SessionContext, it may not be. However, this is exactly what Hibernate is doing when it needs to get a reference to the container provided transaction....and Hibernate is used from with SLSBs frequently. So, I'm going to go with it.

I'm actually thinking of writing a dynamic proxy (because AOP has not yet broken our corporate IT wall yet either) to make sure this code is being called before each Hibernated business object method. I will only call this code if a Hibernate session is not already attached to the thread via a ThreadLocal.

I'll post later to let you know how it works out. Thanks, again.
Thanks! I'll try that and see what happens. We're running in Weblogic, so I'll see if there is an associated class.

Hibernate has the TransactionManagedLookupFactory that can appropriately return the transaction manager given your context properties.
[ August 12, 2005: Message edited by: Jeff Wisard ]
Yea, I've seen the getCurrentSession() method and how it works. Two problems, though. First, we're stuck on Hibernate 2.1.6 for the immediate future. The getCurrentSession() method was introduced in Hibernate 3. Secondly, I have requirements to be able to run our code external to the container. This means that we can't manage the session factory from JNDI (at least without some logic to determine where we are running). It also means that even when we upgrade to Hibernate 3, we can't use the getCurrentSession() method.

So, I'm back to the same problem. I know that what I want to do is possible, because the Spring Framework does it using its JtaTransactionManager that hooks into the container provided transaction framework. But, like I said, I can't use Spring.

Any other help?
Long winded explanation of question commences:

There is a popular pattern when using Hibernate within a web application where a filter is used to open a hibernate session when a request has begun and closes it when the request ends.

I would like to be able to do something similar with my Stateless session beans. However, what I would like to be able to do is listen for when the CMT Transaction ends and close the hibernate session then. So, it would go something like this:

1. A transaction is begun when a stateless session bean method is called (the transaction setting is 'Required'). This may or may not be the bean that makes use of Hibernate.
2. A SLSB method that uses Hibernate checks a ThreadLocal to see if a hibernate session exists on this thread. If not, it creates the session, and also registers some kind of listener on the container-provided JTA transaction via the Synchronization interface (presumbaly). Note that I said Synchronization...not SessionSynchronization. I can't use SessionSynchronization because this is a SLSB.
3. The method does its database work using Hibernate.
4. The method ends. This does not necessarily mean the transaction ends, so I don't necessarily want to have the hibernate session closed yet. I may want to use the same hibernate session again within the same transaction but from another method call or SLSB.
5. The transaction ends. At this time, my listener is informed and I close the Hibernate session, thus committing any database changes. I also remove the Hibernate session from the ThreadLocal.

I know that this is possible, because Spring does it (or something very similar). However, I am unable to use Spring for political reasons within my company. So I need to make a home grown solution.

The part that I haven't figured out yet is how to attach a listener to the CMT (JTA) Transaction. I think I can do this within a SLSB method:

TransactionManager mgr =

Transaction tran = mgr.getTransaction();


But is it okay to assume that the UserTransaction returned from the SessionContext can be cast to a TransactionManager?

Is there a better way to do what I want? I've done a lot of searching without success for an answer...

[ August 11, 2005: Message edited by: Jeff Wisard ]
Thanks Junilu. Unfortunately, we don't have the budget for RoboHelp. I'm looking for something open source (or otherwise free as in beer). Any other suggestions?
Hey all,

I am working on a web application that needs to provide context sensitive help for the user. I was hoping to find an open source library or framework that can plug into a web application (built with Struts) that can ease the pain, but I haven't been able to find a thing. Can anyone make a suggestion?

We are primarily interested in something that can make internationalization easier and can be customized to display different documents (or not display them) based on the user's authorizations. Anything would help, though, because we don't want to have to roll our own if we can prevent it.

Hi Matthew,

Will your new book cover how to plug in Tomcat 5 into an existing Apache web server? (on multiple platforms?)

14 years ago
I have a quick question about threads and transactions.

Does the J2EE spec guarantee a single thread per transaction? That is, during the course of a transction, can the execution of the transaction switch to a different thread?

If a single thread is guaranteed for a transaction, does that hold true when a transaction encompasses calls between applications deployed in different ears on the same JVM (container)?

I have an Stateless Session Bean that has defined all of its methods to require a transaction (transaction set to 'Requires'). I fully expect the client bean of this bean to begin a transaction before calling the methods of my bean. What I am not sure of is how this will work if my bean is deployed in a separate ear file than the client bean.

That is, will my session bean be able to use the transaction started by another bean that calls my session bean remotely from a different deployed ear? Or do they have to be deployed wihin the same ear file for my session bean to use the transaction?

How does this work in a clustered environment?

Originally posted by Andles Jurgen:

When I saw the ? in the hibernate generated SQL I thought only half the job was being done and that I had done something wrong in my mapping file(because I didn't see where the 'PreparedStatement' class substitutions were being done.) By the way, why do I not see these setXXX() calls? Because it's not relavant, not efficient???

Thanks for the help guys.

In your you should see an entry like this:

### log JDBC bind parameters ###

Simply uncomment the line and set the value to 'debug' like so:

### log JDBC bind parameters ###

When you do this, you'll be able to see the bind parameter values that hibernate will use to complete the SQL that it has written. I'm guessing that Hibernate executes the SQL (in my mind, at least) using PreparedStatements in JDBC. So, it binds the values retrieved from your objects to the '?' place holders much like you would if you were using JDBC.

Hope this helps.
I have been asked to make calls from EJBs to native c/c++ libraries using JNI. I have read that this is a bad idea but I don't know enough about how the two technologies would interact to be able to defend the notion of NOT doing this or proposing alternate solutions. Can anyone help me out with this?
What I need are:
-- Reasons why making JNI calls from an EJB are a bad idea. (Things like threading, transactions, etc. in detail on why its bad/dangerous)
-- Possible work-arounds or other solutions. I've heard that using a separate RMI server to make the JNI calls might work....but I'm worried about scaleability and performance.
Question in the case where you keep a single FileChannel open for the duration of your server:
What are the threading issues? If they are simply about where the file position is, that can easily be circumvented by using the absolute indexing methods on the channel. Are there other threading issues outside of file position?
Wow! Very cool! I didn't know about this.
Hello everyone,
In the contractors assignment, I return the trimmed version of the fields of my records from the readRecord method. That is, any trailing whitespace on each field is removed.
This means, of course, that when I create a new record or update a record, I have to put that whitespace back in the field before writing it. i.e. I have to pad each field with spaces so that it is the correct length.
A problem I encountered is that the data file is encoded in 8-bit US Ascii. When I would write a space character to a ByteBuffer (I am using NIO classes), that character is two bytes long. This caused a few problems, including buffer overflow exceptions.
So, I simply cast each space character to a single byte before writing it. This works fine.
However, I just came across the Charset, CharEncoder, and CharDecoder classes that are new with NIO and JDK 1.4.x. Has anyone used these classes for converting data between Unicode and US 8-bit Ascii for data files? I am thinking that I should use these classes instead of casting to a byte...but I'm not sure to what extent I need to use them. Should I run all the data that I read and write through the encoder or decoder classes first?
How important is this issue?