Win a copy of Micro Frontends in Action this week in the Server-Side JavaScript and NodeJS forum!

Chiang Guo

Greenhorn
+ Follow
since Aug 06, 2002
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Chiang Guo

I have been reading good discussions and comments here for scea, some of my experience might be helpful for others too. The part 1 test is not very difficult, guess it's not designed to be tough but rather be a motivation to learn, indeed I have learned a lot.
I was wrong on two questions, one in security(50%) and one in legacy connectivity(80%), so must be 2 on security and 5 on the other.
1. read cade-roberts book very carefully.
2. questions use syllabus closely, so make sure you have a good understanding on each. e.g which part of firewall would affect protocols,
port filering, address filering, content filering, address translation,
http, https, iiop, jrmp
so there are 4*4=16 cases you can investigate.
3. mock tests are not very close to real one, but it's good for learning, i scored usually 75-90% on them.
Thanks for your good points!
Another point I think is SFSB would be better for controlling transactions, though servlets could also do transaction.
Some question in mock test for scea prefers using servlet to control session than stateful session bean, even when the web application is transaction-based. I feel that it would make more sense to use stateful session bean as EJB clearly states that it's best used for transactional, persistence based and distributed applications. Does anyone here have similiar thought?
I am wondering because it's in EJB2.0 not in 1.1, could someone give a light on this? Also what about EJB QL? Thanks.
you may use setMaxLimit() method on
oracle.jdbc.pool.OracleConnectionCacheImpl
class
If objects on database server corresponding to PreparedStatement is resusable is really up to implementation of JDBC driver and dbms.
On the other hand, if a new PreparedStatement is created using a new connection instead of the one previous PreparedStatement is created from, most likely the sql command in database won't get reused, take oracle for example, each connection represents a different database session and sql commands for different sessions are allocated on different memory locations.
If you want to reuse the same PreparedStatement object, then you should not call close() method, instead call clearParameters() on PreparedStatement object everytime you reuse it.
Otherwise, calling close() is telling JVM to release the object and it won't be able to be referenced again. Some JDBC driver(like oracle) can cache Connection object but I do not know if there is any that caches Statement objects.