Thomas, thanks for the info! To answer your questions, We are considering
ODMG, because the faq/etc seems to recommend it. If you think we'll be okay
with PB, then no problem here. Again, I'm new to OJB and its best practices.
As far as data access, we are going do this as follows: Struts webapp calls
factory (IMemberServiceFactory) to get a new instance of our implementation
(MemberServiceImpl) via an interface (IMemberService); this provides
transparent hooks into OJB (a la, "register(User)"). Implementation will get
the Database, Transaction, etc. from OJB on each request. User data will be
passed between the back-end and servlet as a Data transfer object (UserView)
("getUser(email)").
Each request is self-contained and does not span multiple HTTP requests.
That is, each request to the servlet will run a one-time OJB transaction on
its own local server. The only distributed aspects will be for maintaining
the user cache (so that the same user, refreshing his profile will see the
most current data). There won't be much overlap of data (nested objects), so
maybe we don't need to worry about locking. Not sure.
Thanks again for your help!
Andrew
-----Original Message-----
From: Thomas Mahler [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 23, 2002 1:40 PM
To: OJB Users List
Subject: Re: Multiple VM's
Hi Andrew,
Lienhard, Andrew wrote:
> We're considering using OJB for a large web project this spring. We run
> about 5 servlet engines (Resin) in production. We're can I find
> documentation on how to configure OJB to run across mulitple machines for
> caching/locking?
apart from the C/S mode document shipped with documentation and the
hints in OJB.properties you won't find much about this scenario.
> I assume this is something that is configured in
> OJB.properties (LockMapClass ??). Are there any gotchas to consider? The
app
> is for user management, so caching is not that critical.
>
Are you working against the PersistenceBroker API or against ODMG?
Most servlet apps I know are using DAO pattern for data access. IMO the
PersistenceBroker API fits the DAO approach much better than ODMG.
with PB things are pretty simple.
You can use optimistic locking (version- or timestamp based) to detect
write conflicts.
You can use explicit calls to the PB API for cache management. (E.g a
cache clear).
with ODMG things are a bit more complicated. If you want to have a
proper transactional isolation across VM's you have to use the
PersistentLockMapImpl to handle the lockmanagement accross VM's.
This is done in OJB.properties.
there should be no further caveats.
cheers,
Thomas
> Thanks,
> Andrew
>
>
>
> Andrew Lienhard
> Web Technology Manager
> United Media
> 200 Madison Avenue, 4th Floor
> New York, NY 10016
> http://www.comics.com
> http://www.dilbert.com
> http://www.snoopy.com
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
