Thanks Matt. I will have a look at this.

René

-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Matt Raible
Gesendet: Freitag, 1. Juni 2007 07:10
An: [email protected]
Betreff: Re: [appfuse-user] DB Transactions in Service Layer?

Transactions are automatically started for you in the service layer
using Spring AOP. If you throw a RuntimeException, the transaction
will automatically be rolled back. If you want to throw a checked
exception, you'll need to do some extra configuration. Also, you
should be able to use Spring's @Transactional annotation.

http://tinyurl.com/2yr2gz

Matt

On 5/31/07, René Günther <[EMAIL PROTECTED]> wrote:
> Thanks for your reply!
> I am not sure wether I made my point clear.
>
> Request 1 of me
> I want to save a new document assigned to the enabled user A. Before calling
> the „document save" method of the dao, user A is fetched and checked wether
> he is enabled in the service layer. Since request 1 isnt finished yet, user
> A is still enabled.
>
> Request 2 of some other guy
> He wants to disable user A. Before calling the „user save" method of the
> dao, in the service layer it is checked wether any documents are assigned to
> the user. Since request 1 isnt finished yet, no documents can be found.
>
> Now both requests are successfull and in the database there is now a
> document assigned to a disabled user. So I had the permission to assign the
> document at the start of my request, but I hadnt at the end of my request
> when the table update is taking place.
>
> Id like to lock user A after he is being fetched in the service layer to
> check wether he is enabled until the new document is saved.
> Id like to lock user A before I check for assigned documents until the
> disabled user A is updated.
>
> Thats why I want to begin the transaction in the service layer.
>
> Regards
> René
>
> PS: I am still looking for something what is nicely done in a SAP based
> enviroment. There you can lock business objects. There can only be one lock
> on a business object at the same time. This locking is not done by the
> database, it is done by a lock server.
> http://help.sap.com/saphelp_nw70/helpdata/en/7b/f9813712f7434be10000009b38f8
> cf/frameset.htm
>
>
>
> Von: Michael Horwitz [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 31. Mai 2007 19:44
> An: [email protected]
> Betreff: Re: [appfuse-user] DB Transactions in Service Layer?
>
> Is there any specific reason you want to disable the user mid-action?
> Presumably user actions are short lived, so if user A has the necessary
> permissions at the start of the request, it should stay that way until the
> next user request?
>
> Mike
>
> On 5/31/07, René Günther <[EMAIL PROTECTED]> wrote:
> If I call document.getUser().setVersion(null) Hibernate throws
> org.hibernate.StaleObjectStateException if the other guy disables User A.
> This could be a solution. But maybe this is the wrong approach?
>
> -----Ursprüngliche Nachricht-----
> Von: René Günther [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 31. Mai 2007 17:57
> An: [email protected]
> Betreff: [appfuse-user] DB Transactions in Service Layer?
>
> Hello,
>
> assume I got a webapp where documents are assigned to users. The user must
> be an enabled user. I want to assign a document to user A who is enabled
> when the service layer is processed:
>
> if (document.getUser.getEnabled())
>  dao.save(document);
>
> But it the very short time between the check in the service layer and the
> real table update in the database layer, some other guy disables user A. The
> update of the document should fail!
>
> So do I have to implement the check in database layer? What do you suggest?
> Can I lock the User instance in short time between
> document.getUser().getEnabled() and SQL statement to update the document?
>
> Thanks
> René
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
http://raibledesigns.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to