James Du

Hi guys,

I'm recently working on a project where corba is needed, since I'm quite new with corba, some e-book recommendations on it would be greatly appreciated. I hope the examples in the book in writen in Java and the explanation is as straightforward as possible, is there an Action series book on Corba?

Thanks

However the containers chose to cache the entity beans as well

Hi, Valentin

I am wondering what do you mean by chose to cache.... Since the pool is must, what do you think the container could use it otherway ?


regard,
James

Thanks for all,

It seems that I should go deeper in the JDK 1.2

Hi Dan,

I share the same question with you, besides that, I also wonder if there exist a type of SSL which authenticate only the client side.

There's no such a applicable scenario in the real world at all?

regards,
James

I have the same problem, anyone could help please?

Go a little further, what if 2 BMTs' 2 methods are involved?

Thanks a lot
James

Hi Dogra,

I can't understand you very well, while after the studying of the JTA specification, I found that the usage of the UserTransaction could potentially result in a 2-phase commit transaction regless of the fact that only one db is involed. I wonder if the bean-ralated transactions are also treated in this way.

This remains very confusing for me. Could onyone else be in help?

regards,
James

Thanks Dan,

I've read the before, while that still can't solve my problem: If we encounter such question, how to respond ?

What of the following is an applet allowed to do ?
1）It can create as many thresds it wants.
2) It can obtain the users profile name
3) It can connect to the host it downloaded from
4) It cannot write to files at the users computer, howerver, it can read files.

regards,
James

Hi all,

I always encouter the question asking what kind of operations are allowed or not for the applet.

While as per my knowledge, that could be different answers with different JDK versions.

With JDK 1.0, applets are restricted to perform certain sensitive tasks such as reading or writing a system file, as sun put it, it runs in the sandbox.

But with JDK 1.1, a digitally signed applets are treated as local code, which could have full access to the resource if the public key which verify the signatures is trusted.

And with the JDK 1.2, we can further fine-tune the actions allowed for an applet by the means of security policies, which implies the set of actions allowed vary greatly with different policies.

So, how could we respond to such type of question?

Regards,
James

Thanks Deepak

I am here more on studying the EJB contract and limitation than planing a robust real world system. Just want to have a solid understanding about what could happen in a specific conditions.

regards,
James

1. Can I create any new transactions in between existing transactions in CMT or BMT?

About this, I have a little different idea.

Let's suppose the following situation:
1)a BMT bean calls a method, say f1() of a CMT bean.
2)the BMT bean's transaction attribute is configured requirednew
3)in f1(), javax.transaction.UserTransaction.begin() is called

I think the code could run without any problem:
The f1() is invoked with a transaction context and in turn it initiate a new transaction.

if the f1() method of the CMT bean is replaced by a requirednew method of a BMT bean, the situation is the same. a brand new transaction would be initiated.

While if javax.transaction.UserTransaction.begin() is called twice in the f1(), an exception would be thrown.

As for nested transactions, what does it exactly mean? Could anyone shed much lights on this?

Regards,
James
[ February 27, 2005: Message edited by: James Du ]

Thanks Deepak,

After some thoughts, I have some new understanding regarding this questioin.

1. One can feel free to create a Connection(as showed in the above code) and commit it afterwards in the Servlet.

2. Whether the transaction context propagate to the EJBs or not depends on how the transaction context is established. if it's done by simply acquiring the connection via JNDI, then the transaction context does propagate, while if it's done by calling the appropriate JTA method, more specificlly, javax.transaction.UserTransaction.begin(), the transaction context would definitely propagate to the EJBs.

3. In the above code, if the bean's transaction attribute is required or requirednew, the code would run successfully. there would be 2 seperate transactions.

4. If the code enclosing the line bean1.dosth() be replaced with

javax.transaction.UserTransaction.begin()
and
javax.transaction.UserTransaction.commit()

the code would also run successfully and there would be only 1 transaction.

All these are drawn by my one understanding. different ideas are always welcome.

Regards,
James
[ February 27, 2005: Message edited by: James Du ]

In a typical j2ee application, a transaction scope may cover multiple ejb invocations, which in turn involve multiple db connections. my question is that: how can container have the ability of taking all the operations within these connections as atomic.

As per my knowledge, for a DBMS, take oracle for example, transaction can not cross connection, but within it.

What do you think?

Regards,
James
[ February 27, 2005: Message edited by: James Du ]

Hi, all

Please take a look at the following code, f1() is a method of a servlet.
f1(){ // get a connection Context jndiContext = new InitialContext(); DataSource ds = (DataSource)jndiContext.lookup("java:comp/env/jdbc/...") Connection conn = ds.getConnection(); conn.setAutoCommit(false); // get a remote reference of a stateless session bean bean1 = .... // bean1.doSth(); // the transaction attribute of the bean1 is Mandatory // conn.commit(); }

Do you think bean1.doSth() will throw an Exception? Can we consider that the method is called with a transaction context?


Regards,
James

Which protocol has a transaction service associated with it?

What does the sentence exactly mean?

Does it mean that the transaction context could be transfered from one end to the other, or sth more complicated?

Regards,
James

What is true about SSL？
1) Client-side SSL ensures authentication etc. for the client but not for the server
2) Server-side SSL ensures authentication etc. for the server but not for the client
3) Client-side SSL ensures authentication etc. for the server and client
4) Client-side SSL is exactly the same as Server-side SSL

The option 2) is obvious.
As for the 1) and 3), quite hard to choose.

What do you think?

Regards.
James