Hi Laurel,
>1. What happens if the underlying database is modified via some other
>application (since Option B doesn't assume exclusive access to the
>underlying database)? How is the application server notified? Does your
>design require that special triggers be added to the database?
1) When the 'other application' is another application server
(in a scalable environment), distributed notification for the
clustered environment, about the object state update, can be sent
to the participating servers. FrontierSuite supports this.
2) When the 'other application' is like a batch process or some non
managed environment, then as you have suggested, we need to provide
special triggers, specific for each datastore, for notification.
Frontiersuite will be providing this feature in the next release.
>2. Does this design require that the app server implement transactions,
>including isolation levels, at the app server level?
If the solution adopts a pluggable standard based architecture for Conection
Management and Transaction Management, the solution can be
applied both in a managed environment(within a app server) and in a
non-managed environment. For a managed environment, FrontierSuite
can be configured to avail and use the connection management and
transaction management from the managed environment. In a non-managed
environment, FrontierSuite provides its won implementation of JTA and
JCA implemenation.
>3. Does this solution assume CMP? In BMP, the ejbLoad() and ejbStore()
>methods would access/update the database directly using JDBC (and thus
>by-pass your cached state). Or does FrontierSuite do something tricky with
>the data sources and connections?
The solution can be for both CMP and BMP. To know in detail, FrontierSuite
pvides a unified approach for persisting the entity beans, taking the persistence
manager role. In the case of BMP, the solution requires to use
at business object level rathan than at JDBC level.
>Is FrontierSuite a product used by app server vendors, or a product app
>server users purchase as an add-on to their app server?
Frontiersuite can be an add-on for app server users.
FrontierSuite is platform for desiging, developing and deploying EJB
applications (including EJB2.0) along with a sophisticated runtime engine.
The runtime engine can easily be plugged into any application server with
any JDBC supported datastore.
Please visit www.objectfrontier.com
On Thu, 26 Jul 2001 08:30:39 -0500, Laurel Neustadter <[EMAIL PROTECTED]>
wrote:
>Hi Dominic:
>
>I have three questions:
>
>1. What happens if the underlying database is modified via some other
>application (since Option B doesn't assume exclusive access to the
>underlying database)? How is the application server notified? Does your
>design require that special triggers be added to the database?
>
>2. Does this design require that the app server implement transactions,
>including isolation levels, at the app server level?
>
>3. Does this solution assume CMP? In BMP, the ejbLoad() and ejbStore()
>methods would access/update the database directly using JDBC (and thus
>by-pass your cached state). Or does FrontierSuite do something tricky with
>the data sources and connections?
>
>Is FrontierSuite a product used by app server vendors, or a product app
>server users purchase as an add-on to their app server?
>
>Thanks.
>
>Laurel
>
>-----Original Message-----
>From: Dominic Savio [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, July 25, 2001 8:24 PM
>To: [EMAIL PROTECTED]
>Subject: Re: locking Entity Beans
>
>
>Yes Evan,
>
>Option B will be the choice for scalable solution. As you have mentioned
>about caching with option B, underlying architecture in the application
>server can maintain the cached state (state object)of the bean separately
>and all the concurrent beans can load (through ejbLoad) from the state
>object rather than from the database.
>
>The issue comes when one of the client has modified the bean and committed
>the changes. In that case the state object of the bean should be updated so
>that the new clients can get the newly commited state of the bean from the
>cache.
>
>Note that FrontierSuite from ObjectFrontier provides such a runtime solution
>for all application servers in a portable way.
>
> ==========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
> ==========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
