Support Forums: Message List - Design Issue

Design Issue

Fri, 20 Apr 2001 18:09:29 -0400

...

Design Issue

Fri, 20 Apr 2001 17:42:53 -0400

A stored procedure something like this..... (I may have the syntax wrong, been a while. This is for Sybase)...

Design Issue

Thu, 19 Apr 2001 22:20:05 -0400

I would extend option 1 to look up serialized handles to the remote references, get the references using the handles and storing them in the Hashtable....

Design Issue

Thu, 19 Apr 2001 19:21:52 -0400

Stored procedures are "stateless",how it can "detects duplicates",I mean how can it remember if it is a "retry" or an unrelated new call? Can you give an example? Thx.

Design Issue

Thu, 19 Apr 2001 13:47:24 -0400

Updates are most often not idempotent this is true. But if your update is calling some form of stored procedure that detects duplicates and handles them inside the database, then you are OK with making the bean idempotent....

Design Issue

Wed, 18 Apr 2001 20:38:49 -0400

cache the home interfaces instead of the remotes.

Design Issue

Wed, 18 Apr 2001 18:18:16 -0400

Update is not idempotent..right?

Design Issue

Wed, 18 Apr 2001 17:28:00 -0400

If a server fails, the client proxy MIGHT handle it transparently. For instance, WebLogic 5.1.0:...

Design Issue

Wed, 18 Apr 2001 17:14:50 -0400

Client proxy will handle it transparently.

Design Issue

Wed, 18 Apr 2001 16:21:38 -0400

what happens if you are using a clustered enviroment and one of the server crashes and bean references become invalid. How do you handle failover ?

Design Issue

Wed, 18 Apr 2001 16:19:55 -0400

I support the second way of doing, as severe level of pooling problems are expected due to the first design approach.

-Shashi.

Design Issue

Wed, 18 Apr 2001 11:36:31 -0400

If the session bean is stateless, option 1 is OK.
Otherwise, use the approach posted above.

Design Issue

Wed, 18 Apr 2001 10:58:57 -0400

Hi,...

Design Issue

Wed, 18 Apr 2001 10:44:38 -0400

Manoj,...

Design Issue

Wed, 18 Apr 2001 09:55:21 -0400

i will recomnmed here a way which is similar to the u r first option have one class any container class which going to hold the all refernces for all u r beans and other can access this ...due to this design u r lot of resources will be saved ie:- each...