>> so what to you think about non persistent objects or the transient flag?
> Wow, pretty advanced stuff ;)
> First question: why do you need to excange objects? performance? scalability?
> or just business logic needs?
> This is important, since you problem is (if I got this right) that you need to
> exchange trees of ozone objects. Regardless if why find a working solution and
> what it will be, it will probably be to slow to frequently do it "inside"
> business logic just to provide a business process all resources it needs to
> its job done. For this kind of stuff "linking" objects (just like JNDI or even
> better: via JNDI; having a ozone server be the client of another server) would
> be better.
thanx for your quick answer!
hmm, i guess i have to tell you a bit more about our project: its a
configuration and managmentsoftware for networks up to 100.000 clients , and
some are spread across different locations with firewalls, or even no
permanent connection in between (www.asdis.com), so we cant have a database
connection via sockets. the really huge servers have their versant databases
(for smaller networks ozone is also an alternative for these servers), but
there are cooworking controller servers, with ozone installed, so thats
another reason why we cant access these objects with an ozone connection.
we have actionplan tree objects, which are a container classes for action
lists, which themself are container classes for actions. all of them are
OzoneObjects. so you are right, we have a tree of persistent objects. these
objects can get big, so i want to create all my objects inside the database,
and not from the outside and having a commit for every createpersistent and
another point is, inside this cooworking servers i need a different version
of actionplan than on the big server. so actually actionplan is the common
base class for both of them, and this is the one which is transfered.
so since actionplan is the base class its also a ozonecompatibel, but it
doesnt have proxy. its thrown away immediatly after the init method of the
real persistent object is called.
so anyway, wouldnt it be usefull to have also nonpersistent objects inside
the database? i dont know the implications of this and have the inside
knowledge (though its getting better every day ;-) ) , but since ozone
doesnt support makepersistent, there is the implicit assumption that every
ozone compatibel has a proxy, but why cant these non perssitent objects be
treated like any other?