Ogi K

Greenhorn
+ Follow
since Sep 17, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ogi K

Entity Beans are dead! If you haven't figured this out by now, you've been out of touch..

One correction to the above, however, a Hibernate POJO cannot span more than one table at the moment ( neither can entity beans). For this, you'll have to wait for Hibernate 3.

Cheers.
I have a session bean method which has a container managed tx associated with it. It calls a method on a DAO class, which has:

tx = s.beginTransaction();
..
tx.commit();

inside it. The reason being, this method could be called from within an already running JTA tx, or standalone, in which case, it would have it's own tx.

Is there a problem with this approach?
okavazovic, is my first initial "o" and last name "kavazovic." This is complicit with the naming rules...
I a <one-to-many> mapping element, the Hibernate docs says that you specify the column on the CHILD table to be joined with the ID column of the parent table. Is it really possible that you can't join on any other column on the PARENT table, other then the ID column?

<set name="bars">
<key column="foo_id"/>
<one-to-many class="org.hibernate.Bar"/>
</set>

The foo_id is the column on the child table. How about the column on the parent table, Foo?
james, in order to do an update in the object world, you must first get a handle of the object you want to update! -- this is a fundamental difference between the object and the relational word. So, the definition of update in the object world is

1. get a handle of the object you want updated -- i.e. READ IT from DB.
2. change any or all values on it ( excluding primary key..if you change primary key, then you must do an insert ).
3. and then save the object back to the DB, i.e. call 'update' on Session interfacce.

You're probably thinking that this less efficent then doing a straight update, like you can in sql..this is true, but in most use cases, you're only updating objects you have already read..otherwise, you wouldn't know what to update...for other cases, including mass-updates, use JDBC.
Can you provide the code you have in your saveOrUpdatePO method?

Also, the mapping file...

My guess is that you're calling saveOrUpdate on the PurchaseOrder, with NEW LineItems attached to is, and have a cascade-all in your mapping. In this case, Hibernate will determine that you need to do an Update (because PO already exists, but will fail when trying to also updat eh LineItems, since those are brand new...but don't want to speculate...let's see your code first.
sure...check out this site:

http://www.hibernate.org/98.html

Hibernate page, talks about using middlegen.

Also, there's a very useful zipfile download to get you started with using middlegen for Hibernate ( no ejb stuff here ):

http://prdownloads.sourceforge.net/hibernate/?sort_by=date&sort=desc

look for middlegen-hibernate...zip

hope that's enough to get you started.
[ September 22, 2004: Message edited by: Ogi Kavazovic ]
We have a table-per-subclass mapping strategy.

Client --> CLIENT_TABLE
|
-- ClientTypeA --> CLIENT_A_TABLE ( joined on CLIENT_ID )
-- ClientTypeB --> CLIENT_B_TABLE ( joined on CLIENT_ID )
-- ClientTypeC --> CLIENT_C_TABLE ( joined on CLIENT_ID )

However, our Client class is NOT abstract because when we first insert the Client into the DB, we do not know which type of client it is. Later on, the user inputs more information which determines which type it is. At this point, we construct a ClientTypeX object from the Client object and want to update it.
Not too surprisingly, we get a StaleObjectStateException...the desired behavior is for Hibernate to be smart enough to update the Client table and insert into the joined-subclass table for the given Client type. Can Hibernate be configured to handle this??

Thanks.
[ September 22, 2004: Message edited by: Ogi Kavazovic ]
Hello All,

Im a bit confused about the relationship between JTA and CMT ( container-managed txs), and how Hibernate synchronizes with them.

Most docs/forums out there use JTA to imply a user-controlled transaction, via the UserTransaction interface. Hibernate is provided the JNDI lookup name for the UserTransaction object, and it uses it to synch up its own transactions with the UT. That seems pretty clear.

What's not clear is how Hibernate synchs up with CMT? My understanding is that container-managed transactions still use the JTA API, but just not the UserTransaction interface. The provided TransactionManagerLookup class is used to lookup the container's TransactionManager, and then Hibernate can get a handle on the CMT by calling TransactionManager.getTransaction, and synch up with it. Is this correct?

If so, why does the Hibernate code inside the Transaction.begin method require that a UserTransaction class be present via JNDI when using JTATransaction? If Hibernate is used within a CMT, then the presence of a UserTransaction should be irrelevant. It should only ask the TransactionManager for the current transaction ( which would return the CMT ) and go from there. Is this the way it should work? If not, how does Hibernate synchy up with container-managed transactions?

Thanks,
-Ogi.
Hi,

The part that's not clear is who increments the version here? Is the application responsible for it before it calls update, or does hibernate do it? It seems to me that the app. cannot do the increment of the version because how would then Hibernate compare this incremented version to what's in the database? Is there any way the app. can do the increment, like for example, using a sequence table?