|
|
|
| Are there any such mechanism in WAS v6?
As for EJB 3.0, adding interceptors requires annotations that is modification of source code, while I need mechanism without modification of component source code.
| |
| Paul Ilechko 2007-03-21, 7:21 pm |
| mutilin@ispras.ru wrote:
> Are there any such mechanism in WAS v6?
No
>
> As for EJB 3.0, adding interceptors requires annotations that is
> modification of source code, while I need mechanism without
> modification of component source code.
What are you trying to achieve with these interceptors? Maybe we can
propose an alternative solution if we know why you think you need this
non-standard feature.
| |
|
| >What are you trying to achieve with these interceptors? Maybe we can
>propose an alternative solution if we know why you think you need this
>non-standard feature.
It would be great! I want to suspend certains invocations of EJB components to test defferent interleavings of these invocations. To check that component works fine regardless of thread/process schedulling and network delays.
To accomplish this, I need to pass the control before execution of invocation of EJB method to my method, in which I can suspend or continue invocation.
| |
| Randy Schnier 2007-03-21, 7:21 pm |
| Adding interceptors in EJB 3.0 does not require modification of source code -- interceptors can be defined using XML instead. Or you may use a combination of both. In general, all EJB3 functions that can be defined using annotations can alternately be d
efined using XML.
mutilin@ispras.ru wrote:
> Are there any such mechanism in WAS v6?
>
> As for EJB 3.0, adding interceptors requires annotations that is modification of source code, while I need mechanism without modification of component source code.
| |
| Paul Ilechko 2007-03-21, 7:21 pm |
| mutilin@ispras.ru wrote:
[vbcol=seagreen]
> It would be great! I want to suspend certains invocations of EJB
> components to test defferent interleavings of these invocations. To
> check that component works fine regardless of thread/process
> schedulling and network delays.
I don't understand why you would want to do this. Are you testing to see
if the container actually works? That is guaranteed by compliance to the
J2EE specification, and if you find problems you can report them to IBM
through normal support channels. It would seem to be more productive for
you to test your own code, rather than our code ...
| |
|
| >I don't understand why you would want to do this. Are you testing to see
>if the container actually works? That is guaranteed by compliance to the
>J2EE specification, and if you find problems you can report them to IBM
>through normal support channels. It would seem to be more productive for
>you to test your own code, rather than our code ...
I don't want to test IBM container implementation. I want to test concurrent issues of my application. It is true that container do much work to control the concurrency, but there is still a room for errors.
I found at least three sources of errors:
1. If I do some synchronization to shared data manually, I can do something wrong.
2. The incorrect settings of transaction context (Required, ...)
3. Wrong database isolation level (Read uncommited, ...)
| |
|
| >Adding interceptors in EJB 3.0 does not require modification of source code --
>interceptors can be defined using XML instead. Or you may use a combination
>of both. In general, all EJB3 functions that can be defined using annotations
>can alternately be defined using XML.
It is good, that there is no need to modify the code.
Are you planning to make some mechanism for configuration the containers of all aplications working in the same profile? For instance, suppose that I need to add some extra security checks for each incoming call, how can I do that?
| |
| Paul Ilechko 2007-03-23, 7:28 am |
| mutilin@ispras.ru wrote:
[vbcol=seagreen]
> I don't want to test IBM container implementation. I want to test concurrent issues of my application. It is true that container do much work to control the concurrency, but there is still a room for errors.
> I found at least three sources of errors:
> 1. If I do some synchronization to shared data manually, I can do something wrong.
> 2. The incorrect settings of transaction context (Required, ...)
> 3. Wrong database isolation level (Read uncommited, ...)
>
You can test this without needing interceptors. Lots of people already
do. You just need good test tools.
| |
| Paul Ilechko 2007-03-23, 7:28 am |
| mutilin@ispras.ru wrote:
[vbcol=seagreen]
> It is good, that there is no need to modify the code. Are you
> planning to make some mechanism for configuration the containers of
> all aplications working in the same profile? For instance, suppose
> that I need to add some extra security checks for each incoming call,
> how can I do that?
>
You can do that now, using JAAS login modules.
| |
|
| >You can test this without needing interceptors. Lots of people already
>do. You just need good test tools.
Please, could you recommend good tools for testing concurrency issues?
| |
| Paul Ilechko 2007-03-23, 1:23 pm |
| mutilin@ispras.ru wrote:
> Please, could you recommend good tools for testing concurrency issues?
Well, you can use any performance test tool to hit your application with
load and then you can use a tool like ITCAM for WebSphere to see where
you are bottlenecking and to drill down into any specifics of where the
app is locking.
|
|
|
|