As long as they make the same request of the Microsoft guys, I think you
will both be in the same boat (the S.S.Screwed).

Entity Beans will be out. They cannot be reliably used in a
non-transactional manner, nor would you want to.

I would imagine that you will end up with stateless session beans that do
the bulk of you database work. You could abstract the database work out into
another layer if you wish.

I will assume that you can turn auto-commit off on your connection and
perform some sort of commit or rollback on it. Otherwise, there will be no
way to rollback *anything*. Even code you execute in the same method. If
they do not even allow that, I would send an personal email to the "powers
that be" along with a copy of your resignation letter. :-) BTW, how would
they know? They obviously have their heads up so far that they couldn't
possibly know the difference.

If you can turn auto-commit off, you will have to pass the initial database
connection object to the various methods. As long as everyone uses the same
connection object you can do a commit or rollback at any time. You are
basically creating your own, rudimentary transaction manager. You will not
be able to pass the connection between VMs, but your restriction precludes
multiple server-side VMs anyway.

jim

> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Karl Doane
> Sent: Saturday, March 31, 2001 10:36 AM
> To: [EMAIL PROTECTED]
> Subject: Designing Application w/o Commitment Control
>
>
> Hi all,
>      Hopefully you have stopped laughing and I have you
> attention, maybe you
> can help me.  The powers that be, where I work will not allow us to use
> commit/rollback feature with our database.  They would like to
> develop a web
> application folling the J2EE spec and I was wondering if anybody has done
> this with the above limitation?  I am assuming you would have to use
> TX_NOT_SUPPORTED on your EJB's.
>
> What would the perfomance impact be by using tx_not_supported.
> If you set all of your EJB fields then issued your update/insert statement
> and it failed, how hard would it be to set your bean back to what
> it was. I
> guess you could refresh the bean but would that cause a large performance
> problem??
>
> Sorry for all the questions, but I have a sneaky suspicion that
> this project
> is being done to show that J2EE won't work and then they can call in the
> Microsoft clan.
>
> Thanks for any answers
> Karl
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST".  For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to