The query should be: SELECT RoomClient where room_id = :room_id and isScreenSharing != true
Anyhow, I have to admit that I would really liek to get rid of the RoomClient from the database. The RoomClient is a session object. Storing session variables in a database is never a good approach. If we need to have a caching control over the RoomClient we should use something like Ehcache (http://ehcache.org/). If you need the RoomClient as reference under some circumstances you can still store it "on demand", meaning: You persist the RoomClient only if there is really something to store that has this RoomClient as reference. I don't really understand why you needed it for the poll feature, actually also your implementation does delete all roomclients when the room is empty (at least I hope so :D otherwise we have another problem :)))). So if you delete the RoomClient anyway => what should anybody reference this temp RoomClient object if it will be gone again. So please make the RoomClient a static variable in the again, we will have to think about how to really solve it using a caching mechanism but using the database as session cache is not working. Sebastian 2011/11/20 Maxim Solodovnik <[email protected]> > Since the is selection from the DB I will iterate only to get the list of > IDs the call sometheng like: > > SELECT RoomClient where id IN(...) > > OK I will implement your logic tonight > > > On Sun, Nov 20, 2011 at 17:45, [email protected] < > [email protected]> wrote: > >> Returning a Set<RoomClients> based on the a list of streamid ... you >> would need to collect all streamids and iterate two times to the clients >> and a third time to get the RoomCLient from the Set then .... I would not >> do that. >> >> *1 Basic approach* >> Those sync methods => they will always iterate through all clients of ONE >> room >> ... so you can get those RoomClient BEFORE you iterate through the >> connections >> ... and you return a java.util.Map with the streamid as key, so that you >> can access those RoomClients fast >> public Map<RoomClient> getRoomClientsByRoomId >> >> I still think it would perform better to have no Select at all, however >> ... >> doing like that would result in just a single select so I guess we could >> give it a try. >> >> *1A => Extend that basic approach with isScreenClient * >> This could be a basic solution. But additionally those sync methods >> always check for one attribute right now: >> rcl.getIsScreenClient() != null && rcl.getIsScreenClient() >> => because if the RoomClient is a ScreenSharing Connection => we of >> course don't want to send this client a whiteboard object! >> >> So the method should be: >> public Map<RoomClient> getRoomClientsForWhiteboardByRoomId(Long roomId) >> => and only return those clients where isScreenClient != true >> And in the iteration you need to check if the returning Map >> containKey(streamid) => to verify we don't send the wrong connection our >> objects to >> >> *1B => Extend that basic approach with upcoming audio/video components* >> German & Timur's solution with separated Audio/video components will have >> another effect: >> We will have two Connections to each Flash client, but we want ONLY ONE >> to send our whitbeoard objects to. >> So in a later extension the method: >> public Map<RoomClient> getRoomClientsForWhiteboardByRoomId(Long roomId) >> Has to do a SELECT where it only returns those RoomClients that are >> really the "main-netconnection". >> >> >> 1 >> + >> 1 A >> >> should be done right now, >> >> 1 B is something we can do in a second step. >> >> Of course it might be needed in some circumstances to think about if it >> makes sense to have also the ScreenSharing clients in the returning Map, >> but the standard use-case will be NOT to have them. >> >> >> Sebastian >> >> >> >> >> 2011/11/20 Maxim Solodovnik <[email protected]> >> >>> Hello Sebastian, >>> >>> I haven't test so much clients, I have no server with big number of >>> attendees. >>> To resolve the issue I can write a method in clientListManager which >>> will accept Set<IConnection> as a parameter and return all roomClients with >>> ids passed in one request. >>> >>> Or if you feel this would be performance degradation I can move >>> RoomClient out of database. >>> It was necessary bacause in old designs RoomPolls has references to >>> RoomClient, currently it references Users, so it might me easily removed >>> from the DB and will affect nothing. >>> >>> >>> On Sun, Nov 20, 2011 at 16:46, [email protected] < >>> [email protected]> wrote: >>> >>>> Hi Maxim, >>>> >>>> I would like to discuss a design problem of the new architecture to >>>> store the RoomClients in the database. >>>> >>>> Did you see that when iterating through the connections for example in >>>> the method: >>>> >>>> http://code.google.com/p/openmeetings/source/browse/trunk/singlewebapp/src/app/org/openmeetings/app/remote/red5/ScopeApplicationAdapter.java#2504 >>>> >>>> You request on each connection, everytime you iterate throuhg a SINGLE >>>> SELECT on the database to get the roomclient ?! >>>> Meaning if you have 200 people in a conference room you make 200 single >>>> select statements on the database, and as that happens for example for each >>>> time the green dod in video-views starts or stops to blink, or each time >>>> the users sends a new whiteboard event ...actually everytime you sync >>>> ANYTHING to your participants the server will iterate through all session >>>> objects and then does now a SINGLE query for each connection getting the >>>> corresponding RoomClient from the DB. >>>> >>>> Did you ever test the effect when having lets say 500 participants >>>> online, and 150 in a single room and now you send a whiteboard event, how >>>> long does it take?! I mean we make a real-time application? This >>>> implementation does not scale at all. That was the reason why the >>>> RoomClient was a static variable of type HashMap and not in the database. >>>> To be able to access it really FAST. Red5 does something similar for >>>> "sharedObjects" it stores them in the session (using ehCache I think). >>>> >>>> However, there is really need for immediatelly change in that part, >>>> making a single selct ON EACH CONNECTION => this will not fly! >>>> >>>> Can you please propose some concept on that, so we discuss this >>>> together and then implement it. >>>> >>>> >>>> Sebastian >>>> >>>> -- >>>> Sebastian Wagner >>>> http://www.openmeetings.de >>>> http://www.webbase-design.de >>>> http://www.wagner-sebastian.com >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >>> >> >> >> >> -- >> Sebastian Wagner >> http://www.openmeetings.de >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected] >> > > > > -- > WBR > Maxim aka solomax > -- Sebastian Wagner http://www.openmeetings.de http://www.webbase-design.de http://www.wagner-sebastian.com [email protected] -- You received this message because you are subscribed to the Google Groups "OpenMeetings developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/openmeetings-dev?hl=en.
