Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Users List" <torque-user@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41556ADE.4020502@numerixtechnology.de>
Date: Sat, 25 Sep 2004 13:55:58 +0100
From: T E Schmitz <mailreg@numerixtechnology.de>
Reply-To: mailreg@numerixtechnology.de
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
MIME-Version: 1.0
To: Apache Torque Users List <torque-user@db.apache.org>
Subject: Re: Torque BaseXXX in Transaction and the isNew() Method Check
References: <4B913C89C68698458A6AFA37943CB9115CC962@szumail.uswl>
In-Reply-To: <4B913C89C68698458A6AFA37943CB9115CC962@szumail.uswl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hello Michael,

Michael.Kashambuzi@bmwna.com wrote:

> 'm having a problem using Torque-generated classes within a transaction.
> 
> Now, if I'm running in a transaction and the transaction rolls back due to
> some application exception, once the user resolves the problem and attempts
> to re-insert the Person instance, it will not be inserted.  Instead, because
> isNew() now returns false, Torque will attempt to update the record.
> However, this record does not exist in the database since the initial
> transaction rolled back.
> 
> Has anyone come up with an elegant solution for this problem?

I dealt with this problem in the following manner:

Between the Torque generated code and the UI I have a Business layer,
which. Operations on BusinessObjects are all transaction-based and in
some cases they are more complex than just one table insert update.
Therefore the need to be able to roll back the whole transaction exists.

The Business Layer is a set of interfaces, which is implemented by the
DB layer. For instance:

For a table PERSON, we have the Torque generated classes
Person/PersonPeer. For those, I have a wrapper each
TorquePerson/TorquePersonPeer. The latter act as a wrapper round the
Torque generated classes and implement the business layer interface.
(I refer to 'Person' as table object and 'TorquePerson' as business object.)

To solve the rollback problem, you need a shadow table object, which
contains the last committed state of the table object. In the above
example, TorquePerson contains the current and a committed version of
Person.

To create a shadow table object, you cannot use the generated copyInto()
methods as they only use the table object as a twemplate to create a new
similar table object.
Therefore I added the methods klone() and kloneInto() to the Velocity
template Object.vm. This creates a true copy (clone) of the table object.

After a successful commit the shadow table object is kloned from the
current table object using kloneInto(). I do this in a method called
confirm(). This is a method of my Confirmer interface, which all
BusinessObjects implement. This allows me to pass a List or Array of
Confirmers to Session.commit():

public static void commit (Connection connection,Confirmer[] confirmers)
{
     Transaction.commit (connection);
     loop: confirmers[i].confirm();
}

and in case of a rollback I do a reset() instead, which klones the
shadow table object over the current table object.

I hope my posting is not too garbled or more complex than what you were
looking for.


-- 


Regards/Gru�,

Tarlika Elisabeth Schmitz


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org