Original Message-
> From: Geer, Benjamin [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 10, 2002 11:24 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [JBoss-user] J2ee spec thoughts
>
>
> Eric Kaplan wrote:
> > What's my best resource for understa
Thanks Benjamin. That's extremely helpful.
Regards
Eric
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Geer,
Benjamin
Sent: Tuesday, December 10, 2002 11:24 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-user] J2ee spec thoughts
Er
I guess we weren't looking to provide you with easy-to-use-now solutions
:-))
You should be able to isolate the tx in the mbean by writing your own "tx
interceptor" code in your mbean:
/**
* @jmx.managed-operation
*/
public object doSomething(Object data) throws Exception
{
Transaction tx = n
Eric Kaplan wrote:
> What's my best resource for understanding how to turn this
> thing into an mbean and then have the mbean accessed via slsb's?
One easy approach:
1. Write an MBean interface for your component, extending
org.jboss.system.ServiceMBean.
2. Write the implementation of your MBean
PROTECTED]]On Behalf Of Geer,
Benjamin
Sent: Tuesday, December 10, 2002 9:55 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-user] J2ee spec thoughts
Eric Kaplan wrote:
> It spawns threads, so can it be in the ejb tier?
No, that would violate the EJB spec.
I suggest you turn it i
Eric Kaplan wrote:
> It spawns threads, so can it be in the ejb tier?
No, that would violate the EJB spec.
I suggest you turn it into an MBean. This has nothing to do with the
J2EE spec,
but it works wonderfully in JBoss. We're porting one of our
applications, which
has previously run as a stan
through JMS (we use JMS DOF on sourceforge for synchronous
jms request reply through queues).
Eric
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Dan
Christopherson
Sent: Monday, December 09, 2002 6:01 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-
I just downloaded and unzipped JBoss 3.0.2 w/Tomcat 4.1.12. Trying to
access the admin console I get the error below. Is this a JBoss or a Tomcat
error? How can I fix it?
---
HTTP Status 500 - Internal Server Error
type Exception report
message Internal Server Error
description The server encou
- Original Message -
From: "LaBanca, Rick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 09, 2002 10:39 AM
Subject: [JBoss-user] J2ee spec thoughts
> Second, the lack of a "service", "application", "resource" bean or
whatever
> you like to call it. It seems the think
ssage -
From: "Schnitzer, Jeff" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 09, 2002 5:19 PM
Subject: RE: [JBoss-user] J2ee spec thoughts
I need to cache some data that is both physically large and expensive to
compute. I can suffer only one cop
Well, cheat, like Rick! 8^})
have a reference to a singleton in a stateless session bean. Just make
sure the singleton is thread safe, and lacking in bottlenecks if you
have a lot of volume to deal with.
-danch
Schnitzer, Jeff wrote:
I need to cache some data that is both physically large and
On 2002.12.09 14:45:04 -0500 Dain Sundstrom wrote:
>
> On Monday, December 9, 2002, at 01:26 PM, David Jencks wrote:
>
> > Ole suggested sending the prepare and commit messages from the tx
> > manager
> > all at once in different threads. I don't think the tx manager would
> > have
> > a prob
?
Jeff
> -Original Message-
> From: Dan Christopherson [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 09, 2002 1:25 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-user] J2ee spec thoughts
>
> Schnitzer, Jeff wrote:
> >
> > I 100% agree with the need
> Is this really all that important of a use case? I have an
> application
> where I wanted to do something similar. Then I realized that
> while this
> might improve responsiveness on a lightly loaded system, it inhibits
> overall throughput. Given that at any time many different threads are
Schnitzer, Jeff wrote:
I 100% agree with the need for singletons, btw. It's pretty much
impossible to legally cache something in J2EE apps. Not all of us are
building ecommerce systems, we don't always need 100% transactional
integrity.
even in transactional systems, not every access needs t
> From: LaBanca, Rick [mailto:[EMAIL PROTECTED]]
>
> First, the restriction of threading. It would be very useful to use
> threads
> in one atomic call to a session bean. For example, a bean that grabs
data
> from three web sites. I certainly would rather do three parallel
requests
> instead of se
> I aggree; I was just brainstorming after Rick L.'s original
> email. Can
> someone please still answer my "fundamental question" above? I would
> just like to know...
>
Glad I sparked a brainstorm! For my use, just allowing threads only if the
bean is configured to no support transactions
Dain Sundstrom wrote:
On Monday, December 9, 2002, at 12:08 PM, Dan Christopherson wrote:
Dain Sundstrom wrote:
Ah, there's the rub! So my blithering about a hypothetical
'asynchronous task' API needs to be amended again: tasks _must_ run in
their own transaction!
Usually this is accomplishe
On Monday, December 9, 2002, at 01:26 PM, David Jencks wrote:
Ole suggested sending the prepare and commit messages from the tx
manager
all at once in different threads. I don't think the tx manager would
have
a problem supporting this (lots of threads doing work in a tx), it's
the
consiste
On 2002.12.09 13:52:54 -0500 Dain Sundstrom wrote:
> On Monday, December 9, 2002, at 12:34 PM, David Ward wrote:
>
> > I guess my fundamental question is, is it a transaction that has a
> > reference to a thread (which seems pretty limited - probably for good
> > reasons initially), or is it the
Dain Sundstrom wrote:
On Monday, December 9, 2002, at 12:34 PM, David Ward wrote:
I guess my fundamental question is, is it a transaction that has a
reference to a thread (which seems pretty limited - probably for good
reasons initially), or is it the thead that carries the reference to
the t
On Monday, December 9, 2002, at 12:34 PM, David Ward wrote:
I guess my fundamental question is, is it a transaction that has a
reference to a thread (which seems pretty limited - probably for good
reasons initially), or is it the thead that carries the reference to
the transaction (context)?
David Ward wrote:
David Jenks said, "The inheritablethreadlocal doesn't seem to fit with
thread pooling all that well."
I would disagree with this since thread local variables could be reset
before the thread is handed out to someone else.
Duh. Ok - I was being stupid. Of course it doesn't wo
On 2002.12.09 12:42:59 -0500 "LaBanca, Rick" wrote:
> > > So why not allow threading within one call, so long as the
> > threads are
> > > terminated before return? Perhaps give a call to start
> > threads from the
> > > container to keep management simple.
> >
> > I think this is a real problem
Dain Sundstrom wrote:
On Monday, December 9, 2002, at 10:51 AM, David Ward wrote:
Bill Burke wrote:
Answer?
Because there is no way to propagate transaction and security
contexts to
the spawned threads unless J2EE provided a thread creation API.
Bill
I was under the impression that transa
On Monday, December 9, 2002, at 12:08 PM, Dan Christopherson wrote:
Dain Sundstrom wrote:
Ah, there's the rub! So my blithering about a hypothetical
'asynchronous task' API needs to be amended again: tasks _must_ run in
their own transaction!
Usually this is accomplished with a message queue.
Dain Sundstrom wrote:
On Monday, December 9, 2002, at 10:51 AM, David Ward wrote:
Bill Burke wrote:
Answer?
Because there is no way to propagate transaction and security
contexts to
the spawned threads unless J2EE provided a thread creation API.
Bill
I was under the impression that transa
Dain Sundstrom wrote:
On Monday, December 9, 2002, at 10:51 AM, David Ward wrote:
Bill Burke wrote:
Answer?
Because there is no way to propagate transaction and security
contexts to
the spawned threads unless J2EE provided a thread creation API.
Bill
I was under the impression that transa
David Ward wrote:
Bill Burke wrote:
Answer?
Because there is no way to propagate transaction and security contexts to
the spawned threads unless J2EE provided a thread creation API.
Bill
I was under the impression that transaction and security context
propagation was done using java.lang.
> > So why not allow threading within one call, so long as the
> threads are
> > terminated before return? Perhaps give a call to start
> threads from the
> > container to keep management simple.
>
> There are two issues that the spec is dealing with on that
> one. One is
> the attitude: "Appl
> > So why not allow threading within one call, so long as the
> threads are
> > terminated before return? Perhaps give a call to start
> threads from the
> > container to keep management simple.
>
> I think this is a real problem, although I don't think
> threads in an ejb is
> necessarily a g
On 2002.12.09 11:51:48 -0500 David Ward wrote:
> Bill Burke wrote:
> > Answer?
> >
> > Because there is no way to propagate transaction and security contexts
> to
> > the spawned threads unless J2EE provided a thread creation API.
> >
> > Bill
>
>
> I was under the impression that transaction a
On Monday, December 9, 2002, at 10:51 AM, David Ward wrote:
Bill Burke wrote:
Answer?
Because there is no way to propagate transaction and security
contexts to
the spawned threads unless J2EE provided a thread creation API.
Bill
I was under the impression that transaction and security contex
Bill Burke wrote:
Answer?
Because there is no way to propagate transaction and security contexts to
the spawned threads unless J2EE provided a thread creation API.
Bill
I was under the impression that transaction and security context
propagation was done using java.lang.ThreadLocal - a nice
LaBanca, Rick wrote:
While not particular to j2ee, I want to repeat something I've sent to sun
about the spec. Since this is a bleeding edge list, it's the best place to
get my opinion slammed down!
Regarding ejb's. There are two missing elements I don't understand.
First, the restriction of thr
Answer?
Because there is no way to propagate transaction and security contexts to
the spawned threads unless J2EE provided a thread creation API.
Bill
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of LaBanca,
> Rick
> Sent: Monday, December 09, 2002
On 2002.12.09 10:39:25 -0500 "LaBanca, Rick" wrote:
>
> While not particular to j2ee, I want to repeat something I've sent to sun
> about the spec. Since this is a bleeding edge list, it's the best place
> to
> get my opinion slammed down!
>
> Regarding ejb's. There are two missing elements I don
37 matches
Mail list logo
