Maybe server address might be used instead? (id will be taken from the DB on address basis)
On Sun, Jan 27, 2013 at 8:33 AM, [email protected] < [email protected]> wrote: > Currently my only idea to implement this is: > We add a property-bean in our spring config where you can configure the > serverId of the current instance. > > In addition to that, you will also have to configure the session to be > stored in the database instead of memory. From my point of view that makes > sense. You have the possibility to configure the session to be in memory > (default) if switching to cluster, you have to edit > openmeetings-applicationContext.xml to use another Bean. I think that is > comparable to other applications. > > But I am not so sure for the serverId, if > openmeetings-applicationContext.xml is really the right place for it. But > because of lack of other options I would just use it now. > > Sebastian > > > 2013/1/25 [email protected] <[email protected]> > > I simplified the Client object to a single class again: >> org.apache.openmeetings.persistence.beans.rooms.Client >> >> I would like to make it configurable if the Client is stored in the >> database or in the memory (similar to Tomcat Session handling). >> >> But there is no need to create an Interface. My first idea was to have >> two "Client" classes (one DB one memory) and use the interface to hide some >> of the attributes when the object is send to the client. For example the >> new attribute "id", its just an auto-incrementor of the database, for the >> client its useless overhead that eats bandwidth. >> However, Red5 does some reflection to lookup attributes, so it does not >> use the Interface but the concrete class. We will have to design DTOs to >> make our client server communication more "lean" and performing better in >> bandwidth. >> >> However my current problem is that we need to add the information >> "server" to each client before we store it to the database. The streamId >> will be no more unique, each instance of red5 will count its own >> streamid-count and will produce duplicates. >> Only the combination of streamid + server(id) will be unique. >> >> But how can I find out on which server I am currently? >> We can't add a flag "isCurrent" to the database. As all instances write >> to the same database that flag to be true "everywhere" :) >> Also adding a config value won't work as every instance will overwrite >> each other. >> >> Any idea or alternative thought on that? >> >> Thanks! >> Sebastian >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected] >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] > -- WBR Maxim aka solomax
