sandeep vaid

I think there will be no use having hashtable/Vector in EJB.
As each client have different instance of bean object. (i.e it is not multithreaded) so using hashtable/Vector will be overhead only, nothing will be gained out of it.

Hi,

Frnds i don't have much knowledge of j2me but i wana study it and go for sun's j2me certification. pls guide me and send me good books name which i should buy.

Hi,


i have one method in stateless session ejb,i want that method to not to have the transaction for it, But it calls two other methods of same been with diffrent transaction attributs (may be each have required tnx attribute) i repeat in same ejb from where the first method is called. like

in single EJB If i have method

// steteless session ejb starts

//with "Never" as a transaction attribute
pubilc myMethod(){
firstTxn()
secondTxn()
}

//with "required" txn
public firstTxn(){
}

//with "required" txn
public secondTxn(){
}

////ejb ends

client calls myMethod()

i wana know how trxn will propogate in this scenario..


For me in weblogic 8.1 it does not gives any transaction to firstTxn() and secondTxn()

But if i call then with again looking up for home and getting remote/
local interface then making call for firstTxn() and secondTxn() it is working fine.

I wanted to know "Is transaction does not change once it gets first call for it with perticular txn attribut even it calls methods of same ejb with different tnx attributs for method with in it???"




Thanks!!
Sandeep vaid
[ July 15, 2005: Message edited by: sandeep vaid ]

Hi,

You don't have the Method in local Home to remove session Bean so how will u remove. As the local interfaces does not have handles to it.

The Only remove() method is for the enity beans with primary key as parameter.


Thanks !!
Sandeep Vaid

As Ejb Specs says that we can not have the sycronized code inside the ejb so how come we are able to call the vector/Hashtable's functions inside the EJB's They contains all syncronized code inside them. How is possible if it is against the spacifications of EJB.


Thanks!!
Sandeep Vaid

Hi,
The answer for this

"The collection classes that are used for container-managed relationships MUST NOT be exposed through the REMOTE interface of the entity bean."


is that the remote interface can access the collection of the local interfaces throught the collection retuned by the one to many unidirectional CMR, as the Remote Interface can access the local interface in CMR but the other way is not possible because the CMR's can not get return collection of Remote interfaces.

So if there is one side is Remote Interface and the other side is local interace then Remote can get the collection of the local interface in CMR, But the Remote Interface can not expose the collection of the local interface to the remote client.

So this is unidirectional CMR's

Thanks!!
Sandeep Vaid

Hi Bart Laeremans,

I think u r right and that is correct answer to it. If any case the rollback is made that dose not mean how, But if it is there for transaction beforeCompletion() will not be called.

Thanks!!
Sandeep Vaid
[ January 04, 2005: Message edited by: sandeep vaid ]

Hi,

It is given in EJB Sepc page-81 the stateful session beans create()ejbPassivate()/ejbActivate()/remove() execute in unspacified transaction context.
so the transaction related method of the EJBObject can not be called.

But The all these methods execute in client security the context.

And EJB Spec says that Transaction or the security context is reqired to access the resoureces.
Keep in mind the resources can be any type of resources not only the resources that reqiure transaction and not all resources require transaction context but every one requires the security context to access the resources for the security reasons.

Thanks!!
Sandeep Vaid

Hi,

As i think about it the message redilivery is only done in case of BMT if its onMessage() method dose not returns i.e. method goes in an illigalState, so in this case the SystemException and RuntimeException is only way to make the message redilivery.
That's what i know about BMT and MDB.

Thanks!!
Sandeep Vaid

Hi Kathy,

in page 80 spec, the methods of the stateful session bean with CMT are given which can access the methods on SessionContext and the resoures.

there is

ejbCreate
ejbRemove
ejbActivate
ejbPassivate

can access

Resource manager access
Enterprise bean access

even if they are in unspacified transaction context the reason may be this
given at page 81 spec

Accessing resource managers and enterprise beans is disallowed in the session bean methods
for which the Container does not have a meaningful transaction context or client security context.

In above case we have Security context because it is Stateful session bean.

But now my qestion is that if this is allowed because of security context then even In CMT

afterCompletion<

execute in unspacified transaction and have the security context to it then
why

Resource manager access
Enterprise bean access

is not allowed in this case. Pls answer this i have very big doubt.

Thanks!!
Sandy
[ December 07, 2004: Message edited by: sandeep vaid ]

I think the question is not giving correct senario as the expalination in anwer is given as it is duty of the container to decide which Exception to throw depending on client i.e. Remote or local.

Thanks!!
sandy
[ November 29, 2004: Message edited by: sandeep vaid ]

Ok regarding this i got one answer so let me tell u if it is wrong

� Accessing resource managers and enterprise beans is disallowed in the session bean methods for which the Container does not have a meaningful transaction context or client security context.transaction context or client security context.

so we have proper client security context.

Thanks ! ! !
Sandy

In spacification page 80. the table is given in case of stateful session bean.

In that table it is shown that

ejbCreate()
ejbRemove()
ejbPassicate()
ejbActivate()

can have:

access to Resource Managers
access to Enterprise Beans

How these methods access these when they run under unsapcifed context when CMT is used ???

Ok in case of BMT we can access if we begin our transaction with UserTransaction which is allowed in these methods !!!




Thanks !!!
Sandy

I think there is nothing in EJB 2.0 related to NotSupported and
auto-aknowldege
But we know the NotSupported is unspacifed transaction context and for this type of Trancsation context the EJB 2.0 does not have proper specification how container should implement this unspacified context see 17.4.1 of ejb specs and 352 page for this.

So when we chose the MDB with the Unspacifed tracsaction context we are not going for the assured message processing after delivery in onMessage() so here the Transaction acknowlege-mode dose not play part in case of CMT.

Container calls the ejbCreate() when it needes to create new bean instance in the beans' pool at server so and this is Independent to the client invaocation of create(), so How the container can create the client's EJBObject when there is not clinet call for create(). Moreover the creation of the EJBObject need some information of the clinet hence it can not be independent of client call of create().