Basically, you are telling me to move all business logic from APP to an EJB.
I just don't believe it is always desirable to keep all business logic
within EJBs. I don't think a business layer necessarily has to consist of
EJBs alone.
Anh
----- Original Message -----
From: "David Jencks" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, June 16, 2001 8:52 PM
Subject: Re: [JBoss-user] Obtaining a transaction from outside JBoss in
another VM Plan
> Hi,
>
> Ok, this is a slightly different question than the one I thought you were
> asking, and as you say, 2pc is not relevant. Here are my thoughts on your
> proposed design:
>
> 1. I assume that you do not want to hold transactions open while waiting
> for human input. If you need to for some reason, you are apt to be in
> trouble under high load as all those open transactions consume server
> resources for unknown and long periods of time.
>
> 2. I like to think of the architecture of applications like this, in 5
> layers.
>
> presentation layer (what do I see)----------- jsp
>
> presentation manager (workflow control, what do I see next) ------------
> servlet
>
> service subsystem (business logic, data manipulation) -------------session
> ejb
>
> model subsystem (data model, system state) -------------------entity ejb
>
> persistence subsystem ---------(jdbc, db)
>
> I find this really clears up most of my questions about where to put code,
> and makes changes much simpler and more local. In this framework, I
> haven't found a case where knowledge of transactions need to get above the
> business logic layer. I would be curious to know if you have an example
> where this is appropriate.
>
> Thanks
> david jencks
>
> On 2001.06.16 21:07:20 -0400 Phan Anh Tran wrote:
> > Let's forget the 2PC stuff for now...Here is a scenaro:
> >
> > [APP/VM-1] <-> [EJB-1,EJB-2,...EJB-n/JBOSS/VM2] <-JDBC-> [DataStore-1]
> >
> > Each method of each of the EJBs forms a transaction by themselves if
> > noone
> > else issues explicit transaction control a la "begin,commit,abort".
> >
> > APP takes on this role. APP decides the set of EJBs' methods will form
1
> > transaction. Same problem, replace APP with say a servlet running in a
> > Servlet Container in a different VM and you still need the solution
where
> > it
> > is possible to obtain a transaction from a separate VM.
> >
> > Sure, you could move the all the APP transaction control into one single
> > method of one single EJB...but that's not always desirable, I believe...
> >
> > Anh
> >
> > ----- Original Message -----
> > From: "David Jencks" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Saturday, June 16, 2001 11:34 AM
> > Subject: Re: [JBoss-user] Obtaining a transaction from outside JBoss in
> > another VM Plan
> >
> >
> > > Hi,
> > > I think the advice to stay away from distributed transactions is
> > universal
> > > design advice. Basically using distributed transactions just about
> > > guarantees bad performance, as resources get tied up waiting for the
> > 2pc
> > to
> > > make its way to all those other machines or vms not once but twice.
If
> > at
> > > all possible, if you need things to happen on several machines, use
> > > transactional messaging (jms, jbossmq) to break the work up into
pieces
> > > that can be all done on one machine + 1 resource manager + 1 message
to
> > the
> > > next machine. I don't know what jboss/jbossmq actually does in this
> > > scenario, however with a db and a message que as your transactional
> > > resources the db (the slow part) could use 1pc:
> > >
> > > 1. prepare message commit
> > > 2. 1pc on db
> > > 3. commit message.
> > >
> > > This should be roughly as fast as 1pc to the db, since jbossmq is
> > running
> > > in the same vm as the rest of jboss.
> > >
> > > I learned the most about this subject from the (pre ejb) book "High
> > > Performance Client Server" by Loosley and Douglas, isbn 0-471-16269-8
> > >
> > > david jencks
> > >
> > > On 2001.06.16 12:57:44 -0400 Phan Anh Tran wrote:
> > > > We are at design time for a real system. Your suggestion "don't use
> > it"
> > > > is
> > > > that due to JBOSS specific implementation issues or is it a
> > universal
> > > > design advice?
> > > >
> > > > Do you have a copy of Vlada talk? Thanks.
> > > >
> > > > Anh
> > > >
> > > > ----- Original Message -----
> > > > From: "marc fleury" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Saturday, June 16, 2001 3:24 AM
> > > > Subject: RE: [JBoss-user] Obtaining a transaction from outside JBoss
> > in
> > > > another VM Plan
> > > >
> > > >
> > > > > yes anatoly ackerman finished an integration of Tyrex (real DTM)
in
> > > > JBoss.
> > > > >
> > > > > We truly truly discourage the use of DTx (even Vlada matena had a
> > full
> > > > talk
> > > > > on that). So my question is "are you at design time" (in which
case
> > > > don't
> > > > > use it) or is this "real life".
> > > > >
> > > > > marcf
> > > > >
> > > > > |-----Original Message-----
> > > > > |From: [EMAIL PROTECTED]
> > > > > |[mailto:[EMAIL PROTECTED]]On Behalf Of Phan
> > Anh
> > > > > |Tran
> > > > > |Sent: Saturday, June 16, 2001 3:11 AM
> > > > > |To: [EMAIL PROTECTED]
> > > > > |Subject: [JBoss-user] Obtaining a transaction from outside JBoss
> > in
> > > > > |another VM Plan
> > > > > |
> > > > > |
> > > > > |When does JBOSS plan to support the obtaining and using a
> > transaction
> > > > from
> > > > > |another VM? 2.2.3? 2.3? Anytime in the near future?
> > > > > |
> > > > > |[App/VM1] <-> [EJB1,EJB2,.../JBOSS/VM2]
> > > > > |
> > > > > |App needs to setup and control the transactions, so in essence,
my
> > > > > |App needs
> > > > > |to be able to obtain a UserTransaction via JNDI from a separate
> > VM.
> > I
> > > > > |believe this feature is not supported right now, but I would like
> > to
> > > > > |understand when the feature is planned to be incorporated into
> > JBOSS?
> > > > > |Thanks.
> > > > > |
> > > > > |Anh
> > > > > |
> > > > > |
> > > > > |
> > > > > |_________________________________________________________
> > > > > |Do You Yahoo!?
> > > > > |Get your free @yahoo.com address at http://mail.yahoo.com
> > > > > |
> > > > > |
> > > > > |_______________________________________________
> > > > > |JBoss-user mailing list
> > > > > |[EMAIL PROTECTED]
> > > > > |http://lists.sourceforge.net/lists/listinfo/jboss-user
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > JBoss-user mailing list
> > > > > [EMAIL PROTECTED]
> > > > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> > > >
> > > >
> > > > _________________________________________________________
> > > > Do You Yahoo!?
> > > > Get your free @yahoo.com address at http://mail.yahoo.com
> > > >
> > > >
> > > > _______________________________________________
> > > > JBoss-user mailing list
> > > > [EMAIL PROTECTED]
> > > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> > > >
> > >
> > >
> > > _______________________________________________
> > > JBoss-user mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > _______________________________________________
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-user
> >
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
