Thanks for the tip. Unfortunately, this seems to have no affect. I have
tried to set the exclusive-write-access to false, and have played with
different isolation levels as well. I will keep plugging away i guess.
Thanks again!
James Birchfield
Ironmax
a better way to buy, sell and rent construction equipment
5 Corporate Center
9960 Corporate Campus Drive,
Suite 2000
Louisville, KY 40223
|--------+----------------------->
| | "Chris |
| | Miller" |
| | <kiwi@vardus.|
| | co.uk> |
| | |
| | 08/22/00 |
| | 10:32 AM |
| | |
|--------+----------------------->
>-------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: <[EMAIL PROTECTED]>, "Orion-Interest"
<[EMAIL PROTECTED]> |
| cc:
|
| Subject: Re: Transaction problems...
|
>-------------------------------------------------------------------------------------------------------------------------------------|
I'm just guessing, but have you tried setting exclusive-write-access
="false"
in your orion-ejb-jar.xml file? It sounds like Orion is doing some
optimisation to speed things up because it thinks it has exclusive write
access to the database - but your triggers are going behind Orion's back
without it realising. Turning this off might force Orion to call the
ejbLoad.
See \orion\docs\orion-ejb-jar.xml.html for more info.
Worth a try anyway...
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Tuesday, August 22, 2000 2:04 PM
Subject: Transaction problems...
>
> We have been using transactions successfully for a while now....or so we
> thought.
>
> Here is the scenario. We have a series of registration pages on our
site.
> We gather all the information we need, and at the end
> we create a stateless session bean passing it all the information we
need.
> In this session bean, we have seven tables that get
> modified by calling the create method of seven different entity beans.
We
> wrap the whole series of method calls in a usertransaction
> similar to the following:
> <code>
> InitialContext context = null;
> TransactionManager manager = null;
> context = new InitialContext();
> manager = (TransactionManager)context.lookup
> ("java:comp/UserTransaction");
> manager.begin();
> try {
> org = createOrganization();
> orgLoc = createOrganizationLocation();
> orgUsers = createOrganizationUsers();
> orgLocUsers = createOrgLocationUsers();
> createEquipmentTypeOrganization();
> regStatHist = createRegistrationStatusHist();
> notifyUser();
>
> }
> catch(RegistrationException re) {
> manager.rollback();
> throw re;
> }
> manager.commit();
> </code>
>
> From the surface, this looks to work normally. If an excpetion is thrown
> in any method, the entire transaction gets rolled back.
> however, our problem lies within the order that Orion calls the methods
on
> the EJB. When the above code is *NOT* wrapped within
> a transaction, only the ejbCreate of each entity bean gets called.
Nothing
> else. However, wrapped in a transaction like the
> above, immediately after the ejbCreate method is called, the ejbStore
> method is called. Now here is the big reason this is a bad thing.
> All of our tables have triggers on them that set two of the columns.
These
> triggers are set in the database on the insertion of a row. But when
> the ejbStore method is called, it does not sync itself back up with the
> database to get the newly created values in these columns, and does an
> update
> with the locally held values, which happen o be null. It seems that
> ejbLoad should be called *before* ejbStore gets called.
>
> Can someone tell me what I am missing here? In order to get around this
> problem, we have resorted to hardcoding the proper trigger generated
> values into the EJB, but that is a very unflexible solution. Any help
> would be greatly appreciated.
>
>
> James Birchfield
>
> Ironmax
> a better way to buy, sell and rent construction equipment
> 5 Corporate Center
> 9960 Corporate Campus Drive,
> Suite 2000
> Louisville, KY 40223
>
>
>
