hi jim and karl,
personally, i've worked with Java (and a bit
of C++ and Delphi) and though I'm a big
fan of Java related technologies, I would not
throw other options out of the window (no pun
indended ;) including microsoft.
i've seen (too) many successful projects using other
technologies (including dcom, borland's
midas, corba etc using c++ and delphi) even though
they were pretty much tied down to one platform.
and i would agree with most of what Jim has to
say and add: if you don't need j2ee, there's no
need to use it. the entire point of using it imho is
to use the features it provides (transaction mgmt,
object life cycle mgmt, remote connectivity and
security).
-krish
----- Original Message -----
From: James Cook <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, March 31, 2001 5:23 PM
Subject: Re: Designing Application w/o Commitment Control
> 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".
>
>
===========================================================================
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".
